- Email: [email protected]
A procedure for building product models
Robotics and Computer-Integrated Manufacturing 15 (1999) 77 — 87
A procedure for building product models Lars Hvam* Department of Industrial Management and Engineering, Technical University of Denmark 423, 2800 Lyngby, Denmark
Abstract The application of product modeling in manufacturing companies raises the important question of how to model product knowledge in a comprehensible and efficient way. An important challenge is to qualify engineers to model and specify IT-systems (product models) to support their specification activities. A basic assumption is that engineers have to take the responsibility for building product models to be used in their domain. To do that they must be able to carry out the modeling task on their own without any need for support from computer science experts. This paper presents a set of simple, easily adaptable concepts and methods for modeling product knowledge. The concepts and methods are based on well-defined concepts and methods from data modeling (object oriented analysis) and domain modeling (product modeling). The concepts are general and can be used for modeling all types of specifications in the different phases in the product life cycle. The modeling techniques presented have been tested in different companies and have proved to work. 1999 Elsevier Science Ltd. All rights reserved. Keywords: Product modeling; Object oriented modeling; Feature modeling
1. Introduction The aim of this paper is to present concepts and methods that will qualify engineers to build product models, i.e., knowledge bases which contain knowledge and information associated with products in different phases of their life cycles, such as design and production. Based on this knowledge engineers set up specifications like drawings, lists of parts, operation sequences, operation instructions, CNC codes, etc. Product models contain a formalized representation of product knowledge that is normally represented in the heads of skilled engineers (domain experts). An assumption in this article is that, rather than having computer experts interviewing domain experts and building up applications, domain experts should be qualified to build detailed models on their own. Attention has therefore been focused on establishing a simple and easily adaptable way of modeling product knowledge. Central requirements for establishing a product model are identification and modeling of relevant engineering entities e.g., features. Today there do not exist any
* Tel.:#45 45 25 44 35; Fax:#45 45 93 44 67; E-mail: [email protected]
theories or methods for identification of features. This paper introduces a set of pragmatic concepts and methods for identifying and modeling features based on well-established modeling methods and empirical work. The modeling includes the formalization of features into rigid data modeling structures. The starting point for development of a product model is normally a domain analysis, i.e., an analysis of relevant products and related design activities and actors [1]. In this paper it is assumed that relevant parts and subsystems to be modeled have been identified. The result of the domain analysis guides the identification of features. In the next section we present a procedure for building product models. The following sections present a more detailed discussion of the basis for identifying features and how to model features into objects. Finally, a case of modeling product knowledge using the concepts and methods in the procedure is presented.
2. Procedure for building product models Fig. 1 presents a procedure for building product models. The first two phases in the procedure contain an analysis of the specification tasks to be supported (phase 1) and a synthesis (phase 2) where the overall
0736-5845/99/$ — see front matter 1999 Elsevier Science Ltd. All rights reserved. PII: S0736-5845(98)00030-1
78
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 1. A procedure for building product models.
content and structure of the models to build is determined. The synthesis phase sets up the context, view and purpose for the identification and modeling of features in phase 3. The later phases (3—7) are based on the object oriented project life cycle [2, 3]. This paper focuses on the identification and modeling of features in phase 3. The basis for identifying features is set up during the analysis and synthesis in phases 1 and 2. It is not our intention to go into a detailed discussion of how to analyze the specification tasks, but take as a precondition that the overall content and structure of the models to build and the purpose, view and context of the modeling work have all been decided. For further discussion of this see [1, 4, 5]. In order to clarify the basis of the modeling work, we provide a more detailed discussion (in Section 3) of the results of the synthesis phase. Context, view and purpose for the models to be built guides the identification of features to be modeled in phase 3. In addition to analysis of the specification tasks the functionality of the system
and its roles in application are determined using function modeling (IDEF-0) [6]. Phase 3 involves formalization of features by means of the concepts and methods of object oriented modeling. The procedure presented in Fig. 1 follows the object oriented project life cycle (analysis, design, implementation and maintenance). Phase 3 covers the analysis phase containing: E Identification of objects. E Identification of object structures and other relations between objects. E Separating the models into subjects. E Identifying attributes and methods in the objects. The identification and specification of objects are based on the features described in the initial phase. The performance and user interface of the system are defined based on the functional view in the domain analysis (phases 1 and 2).
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
3. Identification of features In this section we discuss the basis for identifying and modeling features. Features are utilized to describe different views on the product throughout the product life cycle [7, 8]. There are a number of examples of different features in literature. According to Salomons et al. [9], these can be divided into two main perspectives, a design perspective (design features) and a manufacturing perspective (manufacturing features). Others define more perspectives, corresponding to the phases in the product life cycle. For example, Tjalve [10] defines five life time phases: development, manufacture, sales/distribution, use and disposal. In general, the exact content of features depends on the perspectives considered. Vesterager et al. [11] state the following general definition of the feature concept: ‘‘Feature: engineering knowledge element or concept. Features are engineering knowledge dependent and as a consequence when talking about concurrent engineering either dependent on the single functions in the engineering process with its purpose, viewpoint, context, and semantics, or referring to a (well)defined engineering knowledge domain (for instance turning). Product specifications are expressed in and/or perceived as features. Features can be basic/atomic (relative to an engineering knowledge domain) or compound/combined (last-mentioned normally dependent on the specific engineering task in question). A physical object described by features can be described in many different ways with highly unlike features, dependent on the perspective or the purpose of the description 2’’ The concept of a feature is here defined as a knowledge element. Features are related to a given function (for example, designing or preparing a method) or to a particular domain (for example, turning or assembling electronic components). Thus, the specific content of the concept of feature (the descriptive elements) can only be specified in relation to a given application area. Products are specified by means of features, which can be related to a single domain or to two or more domains. Features describe an item from a particular perspective (function or domain). Features which describe the same item can therefore differ markedly, depending on the perspective. The exact definition of features depends on the concrete products and aspects to be modeled, and involves asking questions like: 1. Which products or parts are to be modeled? 2. Which part of the product life cycle will be included? 3. What is the functionality of the resulting system?
79
(1) The domain analysis leads to a definition of which products or parts are to be modeled, and the variability of the products and parts to be handled in the models. (2) The product life cycle describes the different phases that a product goes through in its life time (e.g., sales/ contracting, design, methods engineering, production, assembly, delivery, use and disposal). In order to limit the views that have to be incorporated when identifying and modeling features, a decision has to be made as to which phases in the total product life cycle will be included in the models. (3) The functionality of the models is determined based on the domain analysis. The functionality can be described using IDEF-0 function modeling techniques. The structure of the models is decided according to common examples from the literature on how to structure product models, e.g. [12] that separate models into product, factory, process and application models. Also the concepts from the chromosome model [13] — function, organ and part — can be useful when identifying features in the product model. In this presentation the term product model denotes a model containing a description of the product’s functional and structural design, while product-related models are the remaining models related to the product (for example, a process model). Based on this, the general lines for the subsequent tasks of identifying features and building up product and product-related models are drawn up by formulating purposes, views and contexts for the modeling task. The following definitions of purpose, view and context are based partly on ICAM’s use of these concepts [6], and partly on the domain-specific features of the construction of product and product-related models. 3.1. Purpose The purpose specifies the intention of building the model, and what it is to be used for. For example, to support the task of specifying routings, so as to achieve a reduction in resource consumption and shorter throughput time in methods engineering. 3.2. View This specifies the model builder’s view on the given context, for example the methods engineering perspective on the modeling of knowledge and information for building up routings. The view of the modeling task is set up according to which phases in the product life cycle have to be included in the models.
80
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
3.3. Context The model’s context delimits the model in relation to its environment (a larger whole). Thus in connection with the building up of product and product-related models, a specification is given of which product properties, i.e., phases in the product life cycle, and which product or parts are to be included in the model. Based on this the features to be modeled can be listed.
4. Building the OOA-model After the features have been listed, the next question is how to model the features into a rigid data structure in order to implement the feature model. For that purpose we introduce object oriented modeling techniques as a means to model the features, their characteristics and the relations between the different features. In this section we give a brief introduction to the object oriented modeling techniques, and discuss how to model features into objects. 4.1. Basic concepts in object oriented modeling Fig. 2 below shows part of the notation used in objectoriented analysis, as defined by [14]. The notation applies both to individual objects and to classes of objects. A class of objects is a description of one or more objects which have similar properties (attributes) and procedures (services), together with a description of how new objects in the class can be created. The figure shows the following types of relation between objects: 1. Whole-part structures, which define objects which are different, but which form parts of a whole, for example parts of a car: wheels, seats, steering wheel, etc. Relations in whole-part structures are also defined by their cardinality. Thus, a seat corresponds to exactly one car, corresponding to the specification of cardinality in IDEF1 notation.
2. Generalization—specialization structures, which define objects with common information (attributes) and procedures (services), as for example in the case of a car object, which contains general information and procedures about cars, and objects which describe particular groups of cars, such as goods vehicles and lorries, with corresponding information and procedures describing the specific group. 3. Instance connections, which describe relations between individual objects (instances) in the model. As in the case of whole-part structures, this type of relation is also described by its cardinality. The notation for an instance connection is a line between the two objects. 4. Message connections, which describe the information (message) which is sent from a sender object to a receiver object in order to have a procedure executed. The notation for a message connection is a bold line with an arrow pointing to the receiving object. In building up an object-oriented analysis model (OOA model), the activities indicated in Fig. 3 below, in which the OOA model is described as consisting of five layers, are carried out. The individual activities (layers) can be thought of as different perspectives, which together make up the OOA model. The activities are usually performed in the order in which they are listed, but can also be carried out in any arbitrary order. In practice the modeling task is performed as a series of iterations among the various layers of the model. E The subject layer contains a sub-division of the complete domain which is to be modeled in different subject areas. In relation to the use of product modeling, a subject area can, for example, be a product model or a factory model [12]. E The class and object layer contains a list of the classes and objects which have been identified in the individual subject areas. E The structure layer contains the relationships between the objects, i.e., a specification of generalization—specialization and whole—part structures.
Fig. 2. Object-oriented notation [14].
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 3. The five layers of OOA modeling [14, p. 54].
E The attribute layer contains a specification of the information associated with the individual objects, i.e., what the objects know about themselves. E The method layer contains a description of the individual objects methods (procedures), i.e., what the objects can perform. As a basis for building up an OOA model, it can also be useful to perform an analysis of the system’s functionality by using IDEF0 functional modeling. In this way, one obtains a more detailed understanding of the workings of the domain, and thus an improved basis for identifying the individual elements in the five-layer OOA model. The single objects are described using so-called CRCcards [15]. Here the CRC-cards have been extended with sections describing the object’s position in object hierarchies. Another extension is a section with graphical information, e.g., a sketch, and a section called ‘‘Responsibilities’’, that contains a textual description of the object’s mission in the model. Fig. 8 shows an example of a CRC-card. 4.2. Identification and characterization of objects In this section we present the procedure used to identify subject areas and objects, and to specify the objects’ characteristics and mutual relationships. As stated, the objects are modeled based on purpose, view, and context, the features listed, and the function model. The methods described are based on Coad and Yourdon [14]. An object is defined as a element in a domain, which is able to perform in a system by containing information or is able to execute procedures. A class is a description of one or more objects, including how new objects in a class can be created. In this presentation we have chosen to use the word ‘‘object’’ to refer both to an object and a class of objects. When identifying objects in a domain, one can amongst other things search for structures in the domain and for functions (procedures) which can be performed within the domain. In addition, it is possible to focus on which information and procedures are necessary in the given system context, including which general properties and procedures are associated with the domain.
81
During identification of structures, a distinction is made, as previously mentioned, between generalization—specialization structures and whole—part structures. Generalization—specialization structures are identified by starting from the individual objects and investigating whether it would be appropriate in the context (responsibility) of the system to generalize or specialize the object’s properties or procedures. If there are many generalization—specialization structures in the domain, one should start by identifying the simplest and the most detailed structures, and then determine the remaining generalization—specialization structures. Whole-part structures are identified by grouping objects which together form a whole, such as components in a parts list (assembly-parts), objects which can be contained in other objects (container-contents), or objects which together form a collection of objects (collectionmembers). The individual objects are considered as respectively whole-objects and part-objects in the hierarchy, and the object’s contribution to the complete system is evaluated. If the object only contains a status value, the object is removed, and the object’s status is instead added as a property of the topmost object in the hierarchy. Subject areas are defined partly in order to make it possible to get an overall view of an otherwise large and complicated model, and partly to organize the resulting system (the program) into well-defined units. A subject area is defined by grouping the uppermost objects in the structures which have been found, together with the remaining objects according to subject. For example, objects which describe a product’s construction can be placed in one subject area, while objects which describe the product’s manufacturing process are placed in another subject area. An effort is also made to minimize dependencies (structures and instance connections) and communication (message connections) between different subject areas, so that objects which are often connected with one another are as far as possible collected in the same subject area. An object can appear in more than one subject area, in as far as this will make the model easier to understand. Properties (attributes) describe the object’s current state, and are identified by asking how the individual objects are described (what must the object know about itself ?), and which different states the object can be in. A property can be described by a single value or an array (table) of values. When identifying properties in a generalization—specialization structure, the general properties are placed uppermost in the hierarchy, while the specific properties are placed at the bottom of the hierarchy. Properties are as far as possible denoted by terms which are used within the domain, and a permissible interval of values is given, together with units for the
82
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
values (such as $, kg., meters, etc.). In addition, any limitations on the property, such as dependencies on other properties, are specified. Instance connections denote relationships between objects which are naturally related to one another, such as the object ‘‘car’’ and the object ‘‘car owner’’, and are thus in many ways similar to a whole-part structure. Procedures (services) denote a given behavior which the individual object is responsible for demonstrating. Procedures are identified by starting from the various states which an object, according to its specified properties, can be in. This can if necessary be done by using an Object State Diagram, which shows the different states which an object can be in. During the determination of procedures, attention is focused partly on simple procedures, such as creating or making a connection to an object, or definition of the value for a property (attribute value) in an object, and partly on complex procedures, which in turn are divided up into two categories, involving respectively the calculation of object attribute values and the displaying of object attribute values. Procedures are found by asking which calculations the object is to perform, and which information the object is to display. Message connections denote connections in which an object calls another object in order to have a procedure executed. Message connections are found by investigating, for a given object, which procedures in other objects have to be called, and correspondingly which other objects that call procedures are to be found in the given object.
5. Building the OOD-model and programming In this section we discuss the final phases (phases 4—7) in the procedure. When a system is being built up, the perspective changes from being domain oriented (what and which task?) to being implementation oriented (how?). Thus, in the design phase it is made clear how the specified objects can be implemented most efficiently using given software. To put it another way, the analysis model is moved over into a specific hardware and software environment, which is used as a tool for building up the specified system. The design phase is made considerably easier by the use of OOA analysis, as the OOA model forms the immediate basis for the OOD model, which in rough terms is produced by giving more details of the individual objects and if necessary by adding new objects. In the design phase the five-layer model from object-oriented analysis (Fig. 3) is used. The object-oriented modeling techniques make it possible to perform a division of labour between the model builder (domain expert) and the developer of the
computer system (programmer), as the model builder designs the OOA model, while the developer of the computer system programs the system. Construction of the OOD model can be performed as a collaboration between these two participants, as the division of tasks between the system developer and the programmer can be weighted differently in each individual situation (see [1]). The OOD model which is built up forms the basis for programming, and thus if an object-oriented programming language is used makes up the system documentation. In this connection it should be noted that it is necessary to update the OOD model and the computer program simultaneously when the system is maintained. Maintenance of the system is eased considerably by the use of object oriented modeling. [16, p. 238] argues that in traditional system development the costs of programming later versions of a system are almost the same as for version 1, as it is not possible to re-use elements from the previous version. With object-oriented programming, there is a considerable saving in the development of later versions, as it is possible to re-use elements from the first version.
6. A case study The modeling techniques have been tested at Alfa Laval Separation A/S, a SME with 200 employees. The company manufacture decanter centrifuges to separate solid materials from liquids like oil, juice, waste water, etc. In this case study, the choice has been made to focus on the activities involved in specifying windings (one of the components in the decanter) and their operations sequence. Windings are a sub-part of the overall part conveyor. Based on the results of the analysis of the specification tasks, the purpose, view and context for the model can be summarized as follows. Purpose The purpose of the model is to support design and methods engineering for windings in the conveyor. An OOA model is to be built up which can form the basis for constructing an application which contains the necessary knowledge and information for specifying windings and their manufacturing procedure. View The view used in building up the OOA model is that of the phases of design and methods engineering in the product life cycle. General rules for building up windings are to be modeled, so that the model is not just a catalogue of previous designs, but contains the necessary knowledge for specifying new variants of windings within the given solution space, where the desired degrees of freedom are taken into account.
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
83
Fig. 4. The complete task which the system is to deal with in collaboration with the designer and methods engineer.
Context The context of the model is specification of windings in the conveyor. The model supports the construction of drawings, bills of materials and routings for windings in the given product series. This means that the overall model involves a product model for windings at the component level, and a production model containing knowledge and information for the generation of routings. 6.1. Presentation of the domain Besides the listed purpose, view and context I shall give a brief introduction to the domain by presenting the overall function model and the part (windings) to be modeled. The overall task which the system deals with together with the designer and the methods engineer is shown in the IDEF0 model in Fig. 4. From a description (the winding characteristics) of the windings in the conveyor (described by the internal and external profile of the conveyor, the pitch, coating, etc.,), the computer system must generate specifications for the individual winding segments, together with drawings and routings. Fig. 4 shows the functional description of the specification tasks at the top level. The content of the boxes A1 and A2 is described in more detailed diagrams at the lower level. In the further presentation of the case we ignore the production subject of the model and focus on the product subject considering the windings on the conveyor (see Fig. 5). These are composed of a number of winding segments. The external geometry of the winding segments is calculated from a specification of the windings’ external profile and the conveyor’s profile (Fig. 5).
Fig. 5. The conveyor.
In addition to their geometric description, the windings are described in terms of their materials, possibly together with a hard coating or tiles. Tiles are small, hard metal plates, which are soldered or riveted on the extremities of the windings so as to increase their resistance to wear. 6.2. Identification of features Fig. 6 below shows part of a feature which describes windings (a product feature). In the illustration, elements which form part of the complete feature (elements of type ‘‘consists of ’’) are symbolized by circles, and are distinguished from elements describing the individual elements of the complete feature (type ‘‘describes’’), which are symbolized by triangles. The feature for describing windings contains the elements: windings, section interval set, and surface
84
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 6. Feature which describes windings.
treatment zone. It should be noted that the surface treatment zone element, which is part of the overall description of the conveyor, is included because it determines the coating of the windings.
Fig. 7. Product model for windings.
6.3. The product model Based on the identified features, the detailed models have been built up as shown in Fig. 7. The model consists firstly of a whole—part hierarchy, as the coating zone, windings, and section interval set objects are a part of a whole—part hierarchy under the conveyor object, and secondly of a generalization—specialization hierarchy involving coating type (hard coating or tiles), related to the coating zone object. Windings are constructed of winding segments, whose geometry is described by the use of the so-called section intervals, modeled in objects 19 and 20. A section interval is a group of connected values for the angle of the external contour of the windings, the conveyor angle and the angle of cant for a given interval on the conveyor. The angle of cant gives the tilt of the winding segments relative to the long axis of the conveyor. The section interval set object (no. 20) contains knowledge and information about the complete set of section intervals in the conveyor. The conveyor is correspondingly divided into coating zones (end zone, intake zone and cone zone), each of
which has a particular type of coating, which can be hard coating or tiles. Tiles are further divided into Alpha and SH tile types. Each of the boxes in the Fig. 7 denotes an object which contains a description of the object’s state (knows) and of the procedures which the object is able to carry out (does). Fig. 8 shows the section interval set object (no. 19) which, from the external winding profile, conveyer profile and angle of cant, forms the section intervals for the conveyor, and calculates the number of tiles, the welding length and the length of the external contour of the windings. The formulae for these calculations are listed in an appendix to the object. Objects may also contain graphical information. Fig. 9 below shows the conveyor with a graphical depiction of the section intervals. The figure forms part of object 19, and has been included in order to increase the communication value of the model. Fig. 9 shows how a new section interval is created every time there is a break in the external profile of the windings or the conveyor body.
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
85
Fig. 8. Object no. 19: Section interval set.
model. The individual steps of the model are marked to indicate which objects are communicated with. The OOD-model was developed in a cooperation between the domain-expert (who built the OOA-model) and the computer science expert. The OOD-model was programmed by the computer science expert. The time spent building the OOD-model was 40 hours, while the computer science expert spent 250 h on programming the model.
7. Conclusions Fig. 9. Graphical depiction of section intervals.
The dynamic perspective of the model is described using diagrams which show the sequence of events involved in the use of the model. Fig. 10, for example, shows the sequence of events for reading in data for the
The aim of the work presented is to provide engineers with a simple and easily adapted way of modeling features, in order to enable engineers to model their engineering knowledge and information, so that they can — by themselves — specify IT-systems to support engineering activities.
86
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Appendix to Fig. 8 A.1. Calculation of number of tiles, welding length, and length of the outer contour of the windings Number of tiles: Circumference (per cut at the vessel angle) Circumference " ((DY * n * DY * n#s * s) * LKi/s G DY"(DYstart#DYend)/2 AL-tiles: Number of tiles"Circumference/34.5 (mm) SH-tiles: Number of tiles " Circumference/37 (mm) LKi is the length of the cut in the ith interval s is the pitch of the windings DI is the diameter of the conveyor DY is the diameter of the outer contour of the windings Welding length: Welding length Fig. 10. Description of the sequence for reading data into the model.
The modeling techniques for modeling features presented are based on well defined concepts and methods from data modeling (e.g., object oriented modeling, function modeling, and definition of context, view and purpose to guide the modeling task). In addition, concepts from product modeling have been used in order to guide the definition of the overall structure of the models. The modeling techniques are general and can be used for modeling all types of specifications in the different phases in the product life cycle. The modeling techniques have been tested in different companies where they have proved to work. For example, at Odense Steel Shipyard [17], where engineers were qualified to use the modeling techniques within 2—3 days. Engineering students at the Technical University of Denmark have been trained in the modeling techniques during an ordinary term course. Experiences from the course shows that students can learn the modeling techniques within 2—3 days. An important strength of the modeling techniques presented is that they are simple and general. However, an important subject for the future research work will be to set up general guidelines for the detailed identification of features in different phases of the product life cycle.
((DI * n * DI * n#s * s) * LKi/s G #2 * (DY!DI) * LKi/s
"2 *
DI is the diameter at the conveyor body, DY is the external diameter at the windings. If the angle is '(0 the diameter is calculated as the avarage value of Dstart and Dend at the cut. To be calculated for each cut at the conveyor body. Length of the outer cut of the windings (per covering zone): Length" ((DY * n * DY * n#s * s) * LKi/s G (to be calculated for each cut in the covering zone) (All values rounds up to nearest integral number [mm]).
References [1] Hvam L. Application of product modeling — from a work study view point; Ph.D. Thesis; Department of Industrial Management and Engineering, Technical University of Denmark, 1994. [2] Coad P, Yourdon E. Object-oriented analysis. 2nd ed. Englewood Cliffs, NJ: Prentice-Hall, 1991.
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87 [3] Booch G. Object oriented design. Menlo Park, CA: Benjamin/ Cummings, 1991. [4] Hvam L. Using product models in SME’s. Proc 5th Conf on Flexible Automation and Intelligent Manufacturing. 214—225. Stuttgart, 28—30 June 1995. [5] Hvam L. Application of methods engineering principles for product model development and implementation; The 1st Annual Int Conf on Industrial Engineering Applications and Practice; 4—7 December 1996; Houston, TX USA. [6] ICAM project group; Integrated Computer-Aided Manufacturing (ICAM) Architecture Part II, vol. IV-Function Modeling Manual (IDEF-0); Soft Tech Inc. MA USA, June 1981. [7] Kristensen L, Andreasen MM. Features describing products and processes. Proc 6th IPS Research Seminar. Fugls+, March 1992. [8] Meier A. Krupp Atlas Datensysteme GmbH; Advantages of using features to integrate product and process modeling — results of IMPPACT (ESPRIT 2165), 1993. [9] Salomons OW, van Houten FJAM, Kals HJJ. Review of research in feature-based design. J Manuf Systems 12(2): 113—131. [10] Tjalve E. Systematic development of industrial products; Akademisk Forlag, Copenhagen, 1976 (in Danish). [11] Vesterager J, M+lleskov T. Department of Industrial Management and Engineering, TUD, Tuxen Jan og Christiansen Ka re, Odense Steel Shipyard, Lind+; Architecture for a global concurrent engineering system; 2nd deliverable of IMS Test Case, Global concurrent engineering; Department of Industrial Management and Engineering, Technical University of Denmark, 1994.
87
[12] Krause F-L. Knowledge integrated product modeling for design and manufacture, Organization of Engineering Knowledge for Product Modeling in Computer Integrated Manufacturing; 179—219, The 2nd Toyota Conf, Aichi Japan, 2—5 October 1988. [13] Andreasen MM. Designing on a designers workbench (DWB); 9. WDK Workshop, Rigi, March 1992. [14] Coad P, Yourdon E. Object-oriented design. 2nd ed. Englewood Cliffs, NJ: Prentice Hall, 1991. [15] Beck K, Cunningham W. A laboratory for teaching objectoriented thinking. Proc OOPSLA¨89: Object-Oriented Programming Systems, Languages, and Applications; SIGPLAN Notices, vol. 24 (10) October 1989. [16] Adiga S. Object-oriented software for manufacturing systems. Berkely, USA: University of California, 1993. [17] Christiansen KG. Concurrent engineering — A knowledge production concept for a Shipyard. Industrial Ph.D. Thesis; Odense Steel Shipyard, and Department of Industrial Management and Engineering, Technical University of Denmark, 1996. [18] Hammer M, Champy J. Reengineering the Corporation — A manifesto for business revolution, HarperBusiness, 1993. [19] Harrington HJ. Business process improvement — The breakthrough strategy for total quality productivity and competitiveness. New York: McGraw-Hill, 1991. [20] Graham Ian. Object oriented methods. Reading, MA: AddisonWesley, 1991. [21] Meerkamm H. Computer support of design for X — the importance of a product model; Friedrich-Alexander-Universita¨t, Erlangen Nu¨rnberg, May 1993.
A procedure for building product models Lars Hvam* Department of Industrial Management and Engineering, Technical University of Denmark 423, 2800 Lyngby, Denmark
Abstract The application of product modeling in manufacturing companies raises the important question of how to model product knowledge in a comprehensible and efficient way. An important challenge is to qualify engineers to model and specify IT-systems (product models) to support their specification activities. A basic assumption is that engineers have to take the responsibility for building product models to be used in their domain. To do that they must be able to carry out the modeling task on their own without any need for support from computer science experts. This paper presents a set of simple, easily adaptable concepts and methods for modeling product knowledge. The concepts and methods are based on well-defined concepts and methods from data modeling (object oriented analysis) and domain modeling (product modeling). The concepts are general and can be used for modeling all types of specifications in the different phases in the product life cycle. The modeling techniques presented have been tested in different companies and have proved to work. 1999 Elsevier Science Ltd. All rights reserved. Keywords: Product modeling; Object oriented modeling; Feature modeling
1. Introduction The aim of this paper is to present concepts and methods that will qualify engineers to build product models, i.e., knowledge bases which contain knowledge and information associated with products in different phases of their life cycles, such as design and production. Based on this knowledge engineers set up specifications like drawings, lists of parts, operation sequences, operation instructions, CNC codes, etc. Product models contain a formalized representation of product knowledge that is normally represented in the heads of skilled engineers (domain experts). An assumption in this article is that, rather than having computer experts interviewing domain experts and building up applications, domain experts should be qualified to build detailed models on their own. Attention has therefore been focused on establishing a simple and easily adaptable way of modeling product knowledge. Central requirements for establishing a product model are identification and modeling of relevant engineering entities e.g., features. Today there do not exist any
* Tel.:#45 45 25 44 35; Fax:#45 45 93 44 67; E-mail: [email protected]
theories or methods for identification of features. This paper introduces a set of pragmatic concepts and methods for identifying and modeling features based on well-established modeling methods and empirical work. The modeling includes the formalization of features into rigid data modeling structures. The starting point for development of a product model is normally a domain analysis, i.e., an analysis of relevant products and related design activities and actors [1]. In this paper it is assumed that relevant parts and subsystems to be modeled have been identified. The result of the domain analysis guides the identification of features. In the next section we present a procedure for building product models. The following sections present a more detailed discussion of the basis for identifying features and how to model features into objects. Finally, a case of modeling product knowledge using the concepts and methods in the procedure is presented.
2. Procedure for building product models Fig. 1 presents a procedure for building product models. The first two phases in the procedure contain an analysis of the specification tasks to be supported (phase 1) and a synthesis (phase 2) where the overall
0736-5845/99/$ — see front matter 1999 Elsevier Science Ltd. All rights reserved. PII: S0736-5845(98)00030-1
78
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 1. A procedure for building product models.
content and structure of the models to build is determined. The synthesis phase sets up the context, view and purpose for the identification and modeling of features in phase 3. The later phases (3—7) are based on the object oriented project life cycle [2, 3]. This paper focuses on the identification and modeling of features in phase 3. The basis for identifying features is set up during the analysis and synthesis in phases 1 and 2. It is not our intention to go into a detailed discussion of how to analyze the specification tasks, but take as a precondition that the overall content and structure of the models to build and the purpose, view and context of the modeling work have all been decided. For further discussion of this see [1, 4, 5]. In order to clarify the basis of the modeling work, we provide a more detailed discussion (in Section 3) of the results of the synthesis phase. Context, view and purpose for the models to be built guides the identification of features to be modeled in phase 3. In addition to analysis of the specification tasks the functionality of the system
and its roles in application are determined using function modeling (IDEF-0) [6]. Phase 3 involves formalization of features by means of the concepts and methods of object oriented modeling. The procedure presented in Fig. 1 follows the object oriented project life cycle (analysis, design, implementation and maintenance). Phase 3 covers the analysis phase containing: E Identification of objects. E Identification of object structures and other relations between objects. E Separating the models into subjects. E Identifying attributes and methods in the objects. The identification and specification of objects are based on the features described in the initial phase. The performance and user interface of the system are defined based on the functional view in the domain analysis (phases 1 and 2).
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
3. Identification of features In this section we discuss the basis for identifying and modeling features. Features are utilized to describe different views on the product throughout the product life cycle [7, 8]. There are a number of examples of different features in literature. According to Salomons et al. [9], these can be divided into two main perspectives, a design perspective (design features) and a manufacturing perspective (manufacturing features). Others define more perspectives, corresponding to the phases in the product life cycle. For example, Tjalve [10] defines five life time phases: development, manufacture, sales/distribution, use and disposal. In general, the exact content of features depends on the perspectives considered. Vesterager et al. [11] state the following general definition of the feature concept: ‘‘Feature: engineering knowledge element or concept. Features are engineering knowledge dependent and as a consequence when talking about concurrent engineering either dependent on the single functions in the engineering process with its purpose, viewpoint, context, and semantics, or referring to a (well)defined engineering knowledge domain (for instance turning). Product specifications are expressed in and/or perceived as features. Features can be basic/atomic (relative to an engineering knowledge domain) or compound/combined (last-mentioned normally dependent on the specific engineering task in question). A physical object described by features can be described in many different ways with highly unlike features, dependent on the perspective or the purpose of the description 2’’ The concept of a feature is here defined as a knowledge element. Features are related to a given function (for example, designing or preparing a method) or to a particular domain (for example, turning or assembling electronic components). Thus, the specific content of the concept of feature (the descriptive elements) can only be specified in relation to a given application area. Products are specified by means of features, which can be related to a single domain or to two or more domains. Features describe an item from a particular perspective (function or domain). Features which describe the same item can therefore differ markedly, depending on the perspective. The exact definition of features depends on the concrete products and aspects to be modeled, and involves asking questions like: 1. Which products or parts are to be modeled? 2. Which part of the product life cycle will be included? 3. What is the functionality of the resulting system?
79
(1) The domain analysis leads to a definition of which products or parts are to be modeled, and the variability of the products and parts to be handled in the models. (2) The product life cycle describes the different phases that a product goes through in its life time (e.g., sales/ contracting, design, methods engineering, production, assembly, delivery, use and disposal). In order to limit the views that have to be incorporated when identifying and modeling features, a decision has to be made as to which phases in the total product life cycle will be included in the models. (3) The functionality of the models is determined based on the domain analysis. The functionality can be described using IDEF-0 function modeling techniques. The structure of the models is decided according to common examples from the literature on how to structure product models, e.g. [12] that separate models into product, factory, process and application models. Also the concepts from the chromosome model [13] — function, organ and part — can be useful when identifying features in the product model. In this presentation the term product model denotes a model containing a description of the product’s functional and structural design, while product-related models are the remaining models related to the product (for example, a process model). Based on this, the general lines for the subsequent tasks of identifying features and building up product and product-related models are drawn up by formulating purposes, views and contexts for the modeling task. The following definitions of purpose, view and context are based partly on ICAM’s use of these concepts [6], and partly on the domain-specific features of the construction of product and product-related models. 3.1. Purpose The purpose specifies the intention of building the model, and what it is to be used for. For example, to support the task of specifying routings, so as to achieve a reduction in resource consumption and shorter throughput time in methods engineering. 3.2. View This specifies the model builder’s view on the given context, for example the methods engineering perspective on the modeling of knowledge and information for building up routings. The view of the modeling task is set up according to which phases in the product life cycle have to be included in the models.
80
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
3.3. Context The model’s context delimits the model in relation to its environment (a larger whole). Thus in connection with the building up of product and product-related models, a specification is given of which product properties, i.e., phases in the product life cycle, and which product or parts are to be included in the model. Based on this the features to be modeled can be listed.
4. Building the OOA-model After the features have been listed, the next question is how to model the features into a rigid data structure in order to implement the feature model. For that purpose we introduce object oriented modeling techniques as a means to model the features, their characteristics and the relations between the different features. In this section we give a brief introduction to the object oriented modeling techniques, and discuss how to model features into objects. 4.1. Basic concepts in object oriented modeling Fig. 2 below shows part of the notation used in objectoriented analysis, as defined by [14]. The notation applies both to individual objects and to classes of objects. A class of objects is a description of one or more objects which have similar properties (attributes) and procedures (services), together with a description of how new objects in the class can be created. The figure shows the following types of relation between objects: 1. Whole-part structures, which define objects which are different, but which form parts of a whole, for example parts of a car: wheels, seats, steering wheel, etc. Relations in whole-part structures are also defined by their cardinality. Thus, a seat corresponds to exactly one car, corresponding to the specification of cardinality in IDEF1 notation.
2. Generalization—specialization structures, which define objects with common information (attributes) and procedures (services), as for example in the case of a car object, which contains general information and procedures about cars, and objects which describe particular groups of cars, such as goods vehicles and lorries, with corresponding information and procedures describing the specific group. 3. Instance connections, which describe relations between individual objects (instances) in the model. As in the case of whole-part structures, this type of relation is also described by its cardinality. The notation for an instance connection is a line between the two objects. 4. Message connections, which describe the information (message) which is sent from a sender object to a receiver object in order to have a procedure executed. The notation for a message connection is a bold line with an arrow pointing to the receiving object. In building up an object-oriented analysis model (OOA model), the activities indicated in Fig. 3 below, in which the OOA model is described as consisting of five layers, are carried out. The individual activities (layers) can be thought of as different perspectives, which together make up the OOA model. The activities are usually performed in the order in which they are listed, but can also be carried out in any arbitrary order. In practice the modeling task is performed as a series of iterations among the various layers of the model. E The subject layer contains a sub-division of the complete domain which is to be modeled in different subject areas. In relation to the use of product modeling, a subject area can, for example, be a product model or a factory model [12]. E The class and object layer contains a list of the classes and objects which have been identified in the individual subject areas. E The structure layer contains the relationships between the objects, i.e., a specification of generalization—specialization and whole—part structures.
Fig. 2. Object-oriented notation [14].
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 3. The five layers of OOA modeling [14, p. 54].
E The attribute layer contains a specification of the information associated with the individual objects, i.e., what the objects know about themselves. E The method layer contains a description of the individual objects methods (procedures), i.e., what the objects can perform. As a basis for building up an OOA model, it can also be useful to perform an analysis of the system’s functionality by using IDEF0 functional modeling. In this way, one obtains a more detailed understanding of the workings of the domain, and thus an improved basis for identifying the individual elements in the five-layer OOA model. The single objects are described using so-called CRCcards [15]. Here the CRC-cards have been extended with sections describing the object’s position in object hierarchies. Another extension is a section with graphical information, e.g., a sketch, and a section called ‘‘Responsibilities’’, that contains a textual description of the object’s mission in the model. Fig. 8 shows an example of a CRC-card. 4.2. Identification and characterization of objects In this section we present the procedure used to identify subject areas and objects, and to specify the objects’ characteristics and mutual relationships. As stated, the objects are modeled based on purpose, view, and context, the features listed, and the function model. The methods described are based on Coad and Yourdon [14]. An object is defined as a element in a domain, which is able to perform in a system by containing information or is able to execute procedures. A class is a description of one or more objects, including how new objects in a class can be created. In this presentation we have chosen to use the word ‘‘object’’ to refer both to an object and a class of objects. When identifying objects in a domain, one can amongst other things search for structures in the domain and for functions (procedures) which can be performed within the domain. In addition, it is possible to focus on which information and procedures are necessary in the given system context, including which general properties and procedures are associated with the domain.
81
During identification of structures, a distinction is made, as previously mentioned, between generalization—specialization structures and whole—part structures. Generalization—specialization structures are identified by starting from the individual objects and investigating whether it would be appropriate in the context (responsibility) of the system to generalize or specialize the object’s properties or procedures. If there are many generalization—specialization structures in the domain, one should start by identifying the simplest and the most detailed structures, and then determine the remaining generalization—specialization structures. Whole-part structures are identified by grouping objects which together form a whole, such as components in a parts list (assembly-parts), objects which can be contained in other objects (container-contents), or objects which together form a collection of objects (collectionmembers). The individual objects are considered as respectively whole-objects and part-objects in the hierarchy, and the object’s contribution to the complete system is evaluated. If the object only contains a status value, the object is removed, and the object’s status is instead added as a property of the topmost object in the hierarchy. Subject areas are defined partly in order to make it possible to get an overall view of an otherwise large and complicated model, and partly to organize the resulting system (the program) into well-defined units. A subject area is defined by grouping the uppermost objects in the structures which have been found, together with the remaining objects according to subject. For example, objects which describe a product’s construction can be placed in one subject area, while objects which describe the product’s manufacturing process are placed in another subject area. An effort is also made to minimize dependencies (structures and instance connections) and communication (message connections) between different subject areas, so that objects which are often connected with one another are as far as possible collected in the same subject area. An object can appear in more than one subject area, in as far as this will make the model easier to understand. Properties (attributes) describe the object’s current state, and are identified by asking how the individual objects are described (what must the object know about itself ?), and which different states the object can be in. A property can be described by a single value or an array (table) of values. When identifying properties in a generalization—specialization structure, the general properties are placed uppermost in the hierarchy, while the specific properties are placed at the bottom of the hierarchy. Properties are as far as possible denoted by terms which are used within the domain, and a permissible interval of values is given, together with units for the
82
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
values (such as $, kg., meters, etc.). In addition, any limitations on the property, such as dependencies on other properties, are specified. Instance connections denote relationships between objects which are naturally related to one another, such as the object ‘‘car’’ and the object ‘‘car owner’’, and are thus in many ways similar to a whole-part structure. Procedures (services) denote a given behavior which the individual object is responsible for demonstrating. Procedures are identified by starting from the various states which an object, according to its specified properties, can be in. This can if necessary be done by using an Object State Diagram, which shows the different states which an object can be in. During the determination of procedures, attention is focused partly on simple procedures, such as creating or making a connection to an object, or definition of the value for a property (attribute value) in an object, and partly on complex procedures, which in turn are divided up into two categories, involving respectively the calculation of object attribute values and the displaying of object attribute values. Procedures are found by asking which calculations the object is to perform, and which information the object is to display. Message connections denote connections in which an object calls another object in order to have a procedure executed. Message connections are found by investigating, for a given object, which procedures in other objects have to be called, and correspondingly which other objects that call procedures are to be found in the given object.
5. Building the OOD-model and programming In this section we discuss the final phases (phases 4—7) in the procedure. When a system is being built up, the perspective changes from being domain oriented (what and which task?) to being implementation oriented (how?). Thus, in the design phase it is made clear how the specified objects can be implemented most efficiently using given software. To put it another way, the analysis model is moved over into a specific hardware and software environment, which is used as a tool for building up the specified system. The design phase is made considerably easier by the use of OOA analysis, as the OOA model forms the immediate basis for the OOD model, which in rough terms is produced by giving more details of the individual objects and if necessary by adding new objects. In the design phase the five-layer model from object-oriented analysis (Fig. 3) is used. The object-oriented modeling techniques make it possible to perform a division of labour between the model builder (domain expert) and the developer of the
computer system (programmer), as the model builder designs the OOA model, while the developer of the computer system programs the system. Construction of the OOD model can be performed as a collaboration between these two participants, as the division of tasks between the system developer and the programmer can be weighted differently in each individual situation (see [1]). The OOD model which is built up forms the basis for programming, and thus if an object-oriented programming language is used makes up the system documentation. In this connection it should be noted that it is necessary to update the OOD model and the computer program simultaneously when the system is maintained. Maintenance of the system is eased considerably by the use of object oriented modeling. [16, p. 238] argues that in traditional system development the costs of programming later versions of a system are almost the same as for version 1, as it is not possible to re-use elements from the previous version. With object-oriented programming, there is a considerable saving in the development of later versions, as it is possible to re-use elements from the first version.
6. A case study The modeling techniques have been tested at Alfa Laval Separation A/S, a SME with 200 employees. The company manufacture decanter centrifuges to separate solid materials from liquids like oil, juice, waste water, etc. In this case study, the choice has been made to focus on the activities involved in specifying windings (one of the components in the decanter) and their operations sequence. Windings are a sub-part of the overall part conveyor. Based on the results of the analysis of the specification tasks, the purpose, view and context for the model can be summarized as follows. Purpose The purpose of the model is to support design and methods engineering for windings in the conveyor. An OOA model is to be built up which can form the basis for constructing an application which contains the necessary knowledge and information for specifying windings and their manufacturing procedure. View The view used in building up the OOA model is that of the phases of design and methods engineering in the product life cycle. General rules for building up windings are to be modeled, so that the model is not just a catalogue of previous designs, but contains the necessary knowledge for specifying new variants of windings within the given solution space, where the desired degrees of freedom are taken into account.
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
83
Fig. 4. The complete task which the system is to deal with in collaboration with the designer and methods engineer.
Context The context of the model is specification of windings in the conveyor. The model supports the construction of drawings, bills of materials and routings for windings in the given product series. This means that the overall model involves a product model for windings at the component level, and a production model containing knowledge and information for the generation of routings. 6.1. Presentation of the domain Besides the listed purpose, view and context I shall give a brief introduction to the domain by presenting the overall function model and the part (windings) to be modeled. The overall task which the system deals with together with the designer and the methods engineer is shown in the IDEF0 model in Fig. 4. From a description (the winding characteristics) of the windings in the conveyor (described by the internal and external profile of the conveyor, the pitch, coating, etc.,), the computer system must generate specifications for the individual winding segments, together with drawings and routings. Fig. 4 shows the functional description of the specification tasks at the top level. The content of the boxes A1 and A2 is described in more detailed diagrams at the lower level. In the further presentation of the case we ignore the production subject of the model and focus on the product subject considering the windings on the conveyor (see Fig. 5). These are composed of a number of winding segments. The external geometry of the winding segments is calculated from a specification of the windings’ external profile and the conveyor’s profile (Fig. 5).
Fig. 5. The conveyor.
In addition to their geometric description, the windings are described in terms of their materials, possibly together with a hard coating or tiles. Tiles are small, hard metal plates, which are soldered or riveted on the extremities of the windings so as to increase their resistance to wear. 6.2. Identification of features Fig. 6 below shows part of a feature which describes windings (a product feature). In the illustration, elements which form part of the complete feature (elements of type ‘‘consists of ’’) are symbolized by circles, and are distinguished from elements describing the individual elements of the complete feature (type ‘‘describes’’), which are symbolized by triangles. The feature for describing windings contains the elements: windings, section interval set, and surface
84
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Fig. 6. Feature which describes windings.
treatment zone. It should be noted that the surface treatment zone element, which is part of the overall description of the conveyor, is included because it determines the coating of the windings.
Fig. 7. Product model for windings.
6.3. The product model Based on the identified features, the detailed models have been built up as shown in Fig. 7. The model consists firstly of a whole—part hierarchy, as the coating zone, windings, and section interval set objects are a part of a whole—part hierarchy under the conveyor object, and secondly of a generalization—specialization hierarchy involving coating type (hard coating or tiles), related to the coating zone object. Windings are constructed of winding segments, whose geometry is described by the use of the so-called section intervals, modeled in objects 19 and 20. A section interval is a group of connected values for the angle of the external contour of the windings, the conveyor angle and the angle of cant for a given interval on the conveyor. The angle of cant gives the tilt of the winding segments relative to the long axis of the conveyor. The section interval set object (no. 20) contains knowledge and information about the complete set of section intervals in the conveyor. The conveyor is correspondingly divided into coating zones (end zone, intake zone and cone zone), each of
which has a particular type of coating, which can be hard coating or tiles. Tiles are further divided into Alpha and SH tile types. Each of the boxes in the Fig. 7 denotes an object which contains a description of the object’s state (knows) and of the procedures which the object is able to carry out (does). Fig. 8 shows the section interval set object (no. 19) which, from the external winding profile, conveyer profile and angle of cant, forms the section intervals for the conveyor, and calculates the number of tiles, the welding length and the length of the external contour of the windings. The formulae for these calculations are listed in an appendix to the object. Objects may also contain graphical information. Fig. 9 below shows the conveyor with a graphical depiction of the section intervals. The figure forms part of object 19, and has been included in order to increase the communication value of the model. Fig. 9 shows how a new section interval is created every time there is a break in the external profile of the windings or the conveyor body.
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
85
Fig. 8. Object no. 19: Section interval set.
model. The individual steps of the model are marked to indicate which objects are communicated with. The OOD-model was developed in a cooperation between the domain-expert (who built the OOA-model) and the computer science expert. The OOD-model was programmed by the computer science expert. The time spent building the OOD-model was 40 hours, while the computer science expert spent 250 h on programming the model.
7. Conclusions Fig. 9. Graphical depiction of section intervals.
The dynamic perspective of the model is described using diagrams which show the sequence of events involved in the use of the model. Fig. 10, for example, shows the sequence of events for reading in data for the
The aim of the work presented is to provide engineers with a simple and easily adapted way of modeling features, in order to enable engineers to model their engineering knowledge and information, so that they can — by themselves — specify IT-systems to support engineering activities.
86
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87
Appendix to Fig. 8 A.1. Calculation of number of tiles, welding length, and length of the outer contour of the windings Number of tiles: Circumference (per cut at the vessel angle) Circumference " ((DY * n * DY * n#s * s) * LKi/s G DY"(DYstart#DYend)/2 AL-tiles: Number of tiles"Circumference/34.5 (mm) SH-tiles: Number of tiles " Circumference/37 (mm) LKi is the length of the cut in the ith interval s is the pitch of the windings DI is the diameter of the conveyor DY is the diameter of the outer contour of the windings Welding length: Welding length Fig. 10. Description of the sequence for reading data into the model.
The modeling techniques for modeling features presented are based on well defined concepts and methods from data modeling (e.g., object oriented modeling, function modeling, and definition of context, view and purpose to guide the modeling task). In addition, concepts from product modeling have been used in order to guide the definition of the overall structure of the models. The modeling techniques are general and can be used for modeling all types of specifications in the different phases in the product life cycle. The modeling techniques have been tested in different companies where they have proved to work. For example, at Odense Steel Shipyard [17], where engineers were qualified to use the modeling techniques within 2—3 days. Engineering students at the Technical University of Denmark have been trained in the modeling techniques during an ordinary term course. Experiences from the course shows that students can learn the modeling techniques within 2—3 days. An important strength of the modeling techniques presented is that they are simple and general. However, an important subject for the future research work will be to set up general guidelines for the detailed identification of features in different phases of the product life cycle.
((DI * n * DI * n#s * s) * LKi/s G #2 * (DY!DI) * LKi/s
"2 *
DI is the diameter at the conveyor body, DY is the external diameter at the windings. If the angle is '(0 the diameter is calculated as the avarage value of Dstart and Dend at the cut. To be calculated for each cut at the conveyor body. Length of the outer cut of the windings (per covering zone): Length" ((DY * n * DY * n#s * s) * LKi/s G (to be calculated for each cut in the covering zone) (All values rounds up to nearest integral number [mm]).
References [1] Hvam L. Application of product modeling — from a work study view point; Ph.D. Thesis; Department of Industrial Management and Engineering, Technical University of Denmark, 1994. [2] Coad P, Yourdon E. Object-oriented analysis. 2nd ed. Englewood Cliffs, NJ: Prentice-Hall, 1991.
L. Hvam / Robotics and Computer-Integrated Manufacturing 15 (1999) 77–87 [3] Booch G. Object oriented design. Menlo Park, CA: Benjamin/ Cummings, 1991. [4] Hvam L. Using product models in SME’s. Proc 5th Conf on Flexible Automation and Intelligent Manufacturing. 214—225. Stuttgart, 28—30 June 1995. [5] Hvam L. Application of methods engineering principles for product model development and implementation; The 1st Annual Int Conf on Industrial Engineering Applications and Practice; 4—7 December 1996; Houston, TX USA. [6] ICAM project group; Integrated Computer-Aided Manufacturing (ICAM) Architecture Part II, vol. IV-Function Modeling Manual (IDEF-0); Soft Tech Inc. MA USA, June 1981. [7] Kristensen L, Andreasen MM. Features describing products and processes. Proc 6th IPS Research Seminar. Fugls+, March 1992. [8] Meier A. Krupp Atlas Datensysteme GmbH; Advantages of using features to integrate product and process modeling — results of IMPPACT (ESPRIT 2165), 1993. [9] Salomons OW, van Houten FJAM, Kals HJJ. Review of research in feature-based design. J Manuf Systems 12(2): 113—131. [10] Tjalve E. Systematic development of industrial products; Akademisk Forlag, Copenhagen, 1976 (in Danish). [11] Vesterager J, M+lleskov T. Department of Industrial Management and Engineering, TUD, Tuxen Jan og Christiansen Ka re, Odense Steel Shipyard, Lind+; Architecture for a global concurrent engineering system; 2nd deliverable of IMS Test Case, Global concurrent engineering; Department of Industrial Management and Engineering, Technical University of Denmark, 1994.
87
[12] Krause F-L. Knowledge integrated product modeling for design and manufacture, Organization of Engineering Knowledge for Product Modeling in Computer Integrated Manufacturing; 179—219, The 2nd Toyota Conf, Aichi Japan, 2—5 October 1988. [13] Andreasen MM. Designing on a designers workbench (DWB); 9. WDK Workshop, Rigi, March 1992. [14] Coad P, Yourdon E. Object-oriented design. 2nd ed. Englewood Cliffs, NJ: Prentice Hall, 1991. [15] Beck K, Cunningham W. A laboratory for teaching objectoriented thinking. Proc OOPSLA¨89: Object-Oriented Programming Systems, Languages, and Applications; SIGPLAN Notices, vol. 24 (10) October 1989. [16] Adiga S. Object-oriented software for manufacturing systems. Berkely, USA: University of California, 1993. [17] Christiansen KG. Concurrent engineering — A knowledge production concept for a Shipyard. Industrial Ph.D. Thesis; Odense Steel Shipyard, and Department of Industrial Management and Engineering, Technical University of Denmark, 1996. [18] Hammer M, Champy J. Reengineering the Corporation — A manifesto for business revolution, HarperBusiness, 1993. [19] Harrington HJ. Business process improvement — The breakthrough strategy for total quality productivity and competitiveness. New York: McGraw-Hill, 1991. [20] Graham Ian. Object oriented methods. Reading, MA: AddisonWesley, 1991. [21] Meerkamm H. Computer support of design for X — the importance of a product model; Friedrich-Alexander-Universita¨t, Erlangen Nu¨rnberg, May 1993.