Product information systems engineering: an approach for building product models by reuse of patterns

Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

Product information systems engineering: an approach for building product models by reuse of patterns Lilia Gzaraa,*, Dominique Rieub, Michel Tollenaerea a

GILCO Laboratory, INPG, 46 Avenue F!elix Viallet, Grenoble, France LSR Laboratory-IMAG, BP72, 38402 Saint Martin d’Heres, France

b

Abstract This paper deals with an approach for Product Information Systems (PIS) engineering by reuse of patterns. Patterns form generic solutions to problems frequently occurring during PIS specification and implementation. The pattern approach provides an engineering guide to model data by organizing hierarchically and functionally modeling problems and the manner to resolve them. Their use would contribute to accelerate building and implementing product and process models during PIS specification and implementation. Two kind of patterns are distinguished: business patterns used for specification and providing solutions for application field problems and software patterns used for implementation and providing solutions for technical problems (software). A special interest is given to identify and specify different business patterns for product modeling during PIS specification. However, a pattern-based approach can be developed only for disciplines which acquired a certain maturity, i.e. those for which there is both a consensus around a finite set of problems and a variety of known solutions for solving these problems. There is no universal agreement on the knowledge needed in product information systems, let alone on the representation of this knowledge and we therefore find it impossible to discuss product information systems without reference to what kind of knowledge is being managed. The first step consisted thus of constructing a general reference framework based on PIS concepts, providing a common terminology and a semantic of the principal concepts managed in PIS and proposing various models to fix these concepts. It forms a basis for exploring the problems frequently occurring during PIS specification. A pattern language is thus defined to resolve the identified problems, basing partially on existing design pattern catalogues. r 2003 Elsevier Science Ltd. All rights reserved.

1. Introduction Industrial companies must today obtain a rigorous control of the whole product information system (PIS) in order to increase their reactivity to the different changes involved in the product development process or later during the product life cycle. PIS support all types of engineering data used to define, manufacture, and support products. This may include part definitions, specifications, CAD drawings, manufacturing process plans and routings, project plans, control records, engineering change orders, etc. Since the mid-1980s, software industries have developed a new class of software packages, called Product Data Management Systems (PDMs) to support the management of all product engineering data. PDMs *Corresponding author. CRAN Laboratory, University Henri Poincare, UMR CNRS 7039, Nancy, France. Fax: +33-3-83-68-44-37. E-mail addresses: [email protected] (L. Gzara), tollenaere @gilco.inpg.fr (M Tollenaere), [email protected] (D. Rieu).

constitute for industrial companies the core of Product Information Systems, such it is case of Data Base Management Systems (DBMs) for Management Information Systems. They are tool platforms adapted to characterization of items, bills of material, documents, procedures, etc. and providing class libraries dedicated to PIS. PDMs, like described by CimDATA [1] provide two major functions: managing product data (storage, control, retrieval, etc.) and managing product development processes (approval process, authorizations, engineering change orders, deviations, configurations and other processes that impact on product data). Several research works have already been interested in engineering data management. Thus, associated with the AIT1 initiative [2], we quote the RISESTEP project [3] interested in the implementation and validation of STEP shared databases for concurrent engineering. Finally, let 1

Advanced Information Technology Design and Manufacturing.

0736-5845/03/$ - see front matter r 2003 Elsevier Science Ltd. All rights reserved. doi:10.1016/S0736-5845(03)00028-0

240

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

us quote the OPAL project2 [4] whose aim is to provide concepts for processes and information high-quality integration in manufacturing engineering field. These projects are particularly interested in data integration and sharing problems. However, they do not fully deal with the engineering of PIS, i.e. the methodological aspects related to their design and implementation. The development of such systems implies significant investments for the companies. The stakes associated with these methodological aspects are therefore strategic. We are thus focusing our research on those stakes. After describing briefly the principal methodological problems currently faced by industrial companies when PIS development (Section 2), we outline the need for a reuse approach in PIS engineering and we focus on reuse of patterns (Section 3). Section 4 outlines the approach retained to identify and specify business patterns. We present the generic reference framework developed at this end. Finally in Section 5, a pattern language for PIS is presented.

2. PIS engineering problems Just like most information systems, the development cycle of a PIS consists of chronological stages: analysis (users requirements formulation), design (standardized specifications), implementation3 (operational solution; software) and maintenance (evolution). However, the development of PIS in industrial companies currently encounters technical, methodological, organizational and human difficulties that we shall briefly describe below: Analysis: This initial stage is complicated by the lack of ‘‘formal’’ specification models for users requirements formulation, that can easily be understood by the users and by the lack of approaches able to draw up clear and unambiguous requirement specifications. Design: Based on requirements analysis, this stage defines the PIS specifications that will be considered by the developers in charge of their implementation. Currently, this specification is done with no real continuity. Developers have trouble understanding the users description, too informal to get used for implementing the system. The PIS project manager has to write two separate specifications: one file for the users, described from a business point of view, and another file for the developers, described from a technical point of 2

Integrated Information and Process Management in Manufacturing Engineering. 3 Implementation is often carried out by using software packages called PDMS (Product Data Management Systems) such as Metaphase, Matrix, Sherpa, Agilesoft, etc.

view. Any consistency between what is expected and what is actually delivered is purely intentional. Implementation and evolutive maintenance: This stage makes increasing use of PDM systems, whose implementation is extremely complex and complicates the consideration of the above-mentioned specifications. This problem does not only arise during specification and implementation of a PIS, but also when the system is upgraded in the company to allow for organizational changes or evolutive maintenance of the software parts of the system. With respect to these difficulties concerning each stage of the development cycle, we should highlight that the development of such systems is always accompanied with organizational changes (e.g. new objectives, new information flows, evolution of quality procedures) and regular needs evolutions that the PIS must take under consideration and anticipate. Industrial companies are therefore obliged to constantly evolve their PIS, within reduced times in order to avoid the delivery of obsolete systems, unfitted to new organizations. In conclusion, PIS specification and implementation are not currently tackled in a methodical way of computerization, thus generating significant costs and malfunctions. The objective of this research is so to propose a methodological framework for PIS specification and implementation: *

*

offering models of various abstraction levels and one general PIS engineering approach, that cover the complexity of such systems (representation of processes, of versions, etc.), support the exchange between actors and ensure a continuum of transformation during specifications and supporting specification ‘‘by deviation’’ both as regards capitalization and reuse of knowledge already captured in past experiences, in order to accelerate the PIS development process.

3. A methodological approach based on patterns reuse 3.1. The need for reuse in PIS development An efficient way to speed up PIS development consists so of allowing ‘‘deviation’’ specifications, both as regards capitalization and reuse of concepts already encountered and consideration of the software resources (components and systems) available. Consequently, the reuse approach, already effective in software engineering, is a key factor to our PIS development methodological approach, both for specification and implementation of PIS and for their evolutive maintenance. A general definition of the term ‘‘reuse’’ could be: a new development approach by which a system can be built from existing components already described,

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

carried out, tested and accepted in past experiences. The aim is to avoid remaking all with each new application or when changing a software. Thus, we deliberately are in the framework of a capitalization and reuse approach of functional, organizational and software components, at all stages of the PIS development cycle. Today the reuse approach is extensively used in software engineering, and different forms of reusable software components have already been proposed. Three major approaches can be identified: toolkits [5], frameworks [6,7] and patterns [8,9]. A special interest is given to the pattern approach which is, in our opinion, the most suitable form of reuse for PIS engineering. In the next paragraph, we shall develop the concept of patterns and show its advantages for PIS design. 3.2. Patterns The Pattern concept was initially proposed in architecture field by Alexander. In Alexander et al. [8], a pattern is defined as follows: ‘‘Each pattern describes both a problem which occurs over and over again in our environment, and then describe the core solution to that problem, in such a way that you can use this solution million times over, without ever doing it the same way twice’’. Then, the pattern approach has been adopted into software engineering. The first object oriented patterns were introduced by Beck and Cunninghan [10]. More recently, patterns dedicated to Information Systems engineering were proposed by Coad [11], Gamma [9], etc. Several pattern definitions are presented. It comes out from these definitions that a pattern constitutes a knowhow base to solve a problem frequently occurring in a particular field. This know-how allows to identify the problem to solve (for example a BOM4 management), to propose a correct solution to take it into account and finally to give indications to adapt this solution in a particular context. This form of reusable component has several advantages over the toolkits and frameworks approaches previously mentioned. First, the granularity of the pattern provides a very modular reasoning unit, as each pattern exists to solve a standard problem. Integration in the same pattern of a standard problem and a solution forms a component search and integration aid. Naturally, problems have still to be solved regarding pattern composition and organization in order to ensure effective reuse. Furthermore, we should highlight that patterns are ‘‘know-how’’ oriented components, while other forms of reusable components are rather ‘‘know’’ oriented components. These latter provide only solutions to 4

Bill Of Material.

241

problems whereas ‘‘know-how’’ oriented components provide solutions but also a manner to construct these solutions. Patterns form hence an engineering guide by organizing hierarchically and functionally problems and the manner to resolve them. Reuse of patterns is, in our opinion, the most suitable form of reuse for PIS engineering, as it can be used in all stages of the PIS development cycle (analysis, design, implementation). Our objective is thus to adapt the pattern approach to a particular field, that is of PIS, according to a target technology, the PDMs. 3.3. Patterns in PIS The proposed methodological framework is based on a consistent set of models of varying abstraction levels that can be developed by reuse of patterns. Each level proposed must enable a problem to be solved (of a conceptual, organizational, technical nature, etc.) specific to PIS development. Just as for management information systems engineering, two main aspects must be taken into consideration in PIS engineering: first, an organizational aspect specifying the organizational information system (OIS) and with which ‘‘business’’ patterns will be associated, and, second, a technical aspect (software) specifying the part of this OIS which will result in computerization. This is the computerbased information system (CIS) which will result in specifying and reusing ‘‘software’’ patterns. *

*

At organizational level, business patterns are very important, particularly in the stages of formulation of needs and definition of functional specifications. They provide solutions for application field problems so they must be able to take into account a set of information needs associated both with the product description and the various industrial and business processes acting on it. In the definition of organizational level, two forms of modeling are essential: product modeling [12–16] and process modeling [17– 19]. With respect to product modeling, the aim is to use and adapt the modeling solutions taken from industrial and mechanical engineering work, as well as from information systems engineering. With respect to process modeling, we base ourselves on enterprise modeling and integration work [20–22], on techniques of Business Process Reengineering type [23] and on work carried out in information systems process engineering. At technical level, the definition of software patterns is strongly linked to the PDM systems which are at the basis of PIS development. The generic nature of modeling based on software patterns stems from its independence from a PDMs. This modeling is the expression of a technical solution that takes two

242

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261 Name: the name of the pattern, Classification: relating to product or process, Intention: the problem to which the pattern addresses, Motivation: a scenario (an example) of application of the pattern describing, in textual manner and possibly graphic, particular problems, Semi-formal description: the solution suggested by the pattern, expressed using UML6 diagrams and describing in particular the participants in the pattern and their collaborations.

Fig. 1. Formalism for patterns description. Name: item-description pattern. Intention: this pattern is used when some attribute values may apply to more than one object in a class, it allows the management of data from different levels. Motivation: an “aircraft” object knows its own tail number (e.g. N123ABV) and flight’s hours number (e.g. 5000 hours): it also knows about exactly one “aircraft description” object. An “aircraft description” object knows its own manufacturer (e.g. Boeing), model (e.g. 747-400), and standard cruising range (e.g. 8,333 miles). It also may know about some number of “aircraft” objects that depend on that information. Aircraft Description manufacturer model

Aircraft 0..*

1

tail Number flight’s hours nb.

description

standard Cruising Range

Model ? () { }

return description.model

Fig. 2. Example.

major problems into account: implementation of product and process models and communication of the PIS with other systems. With respect to implementation of product and process models, PDMs use database models (relational or object) and ‘‘workflow’’ models. In both cases the models proposed in the tools are extensively used and can thus be integrated in the proposed methodological framework. Definition and specification of software patterns associated with PIS are based on the functions proposed by most PDM systems. With respect to business patterns, mainly used for formulation of needs and definition of functional specifications for PIS, the aim is to identify the problems from the field’s analysis. We give interest in the present research to business patterns and specially those for product modeling.

3.4. Formalism and examples Formalism: Several formalisms can be used to represent a pattern.5 They are characterized by the number of more or less detailed headings that they propose. In order to simplify the comprehension of the patterns we are later presenting (Section 5), we adapted the Gamma formalism by retaining and adapting only 5 Formalisms of Coad [24], Gang of Four or Gamma [9], Fowler [25], etc.

the five headings that we judge essential. These headings are detailed in Fig. 1. We should note that the choice for UML6 formalism was dictated by its capacity to support dialog between users and designers of the system and by the variety of abstraction levels of the diagrams it offers so to ensure a continuum during specification. Examples: To illustrate the notion of pattern, we partially present in the next two design patterns called ‘‘item-description’’ and ‘‘composite’’. These patterns are particularly retained since the problems which they raise are rather general to correspond to problems frequently occurring in PIS. They are hence frequently used in our approach. In fact, to specify business patterns, we need first to identify, through a field’s analysis, the most recurrent problems occurring in PIS field and second, to propose solutions to these problems. This latter phase is made easier by exploiting solutions already proposed in design pattern catalogues and available in software engineering field. Indeed, problems encountered in PIS can be brought into general problems, resolved in these catalogues. To keep illustration homogenous in the whole paper, we use the formalism presented in Fig. 1 to describe these patterns. Moreover, we express the examples in motivation and solutions in semi-formal description headings, using the UML formalism (see Figs. 2–5). The original patterns are described in the literature with 6 Unified Modeling Language; the standard of modeling in objectoriented development (see Appendix A).

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

243

An “aircraft description” object gather all properties common to aircraft objects, such as manufacturer, model, etc. These properties shared by all aircraft objects are described in “aircraft description” level but not handled in aircraft objects. Thus, one aircraft object would consult some of these properties. The properties of “aircraft-description” level remain visible at “aircraft” level by defining consultation methods allowing to propagate a value through associations. Let us take the example of model property: when one requests to an "aircraft" its model, it executes the method: Model?(), defined in its object. This method (pseudo-code return description.model) returns the value of the model attribute in the description of the aircraft which is "aircraft-description" to the aircraft looking for it (through the description role of the association relating an aircraft to its description).

Semi-Formal description: The item description pattern consists of an “item” class and an “item description” class. An “item description” class has attribute values which may apply to more than one “item” class. An “item” class has its own individual assignment of attribute values and various consultation methods to access to the “item description” attributes values. Item

Item Description generic-parameters

1

specific-parameters

0..*

description get generic-parameters ? ( ) { }

return description.generic-parameters

Fig. 3. Solution. Name: Composite pattern Intention: this pattern is used to manage a recursive object composition. It defines composite object class hierarchies and allows the addition of new components. Motivation: Graphic editors allow recursive elaboration of composite figures from simple, predefined figures. A solution is to define one class to manage complex figures and another to manage basic figures (text, circle, etc.). In this case simple objects are treated differently from composite objects, thus making applications weighty.

Figure paint () draw () add(fig) remove(fig) access

Circle paint () draw()

Text paint () draw ()

1..* components

CompoundFigure paint () { } draw() add (fig) remove (fig) access

For any figure of components figure.paint

Fig. 4. Example.

other formalisms. Moreover, we give sometimes precision to motivation and solution headings particularly about behavioral aspects and objects collaboration. We hope thus not denaturing the initial intention of the patterns authors. Item-Description Pattern [11]. We should note that the ‘‘item-description’’ pattern is also known by ‘‘materialization pattern’’. This latter was largely discussed and more formalized with the TELOS language in [27]). Composite Pattern [26]. 3.5. Towards a new development cycle: the For reuse and the By-reuse engineering processes The emergency of the pattern concept leads to think differently about the development cycle of an IS. The

classic development process based on the transformation of user’s specifications into design models and then their implementation on a specific software remains very slow since in every new project, designers develop new models without reference to what is already done in previous projects. Introducing patterns in PIS engineering process so as to accelerate the delays, requires first to construct a patterns library or catalogue. In this order, a new activity is required and consists of identifying and specifying these patterns. Once patterns are built, the development of an IS consists of reusing these patterns. Thus, the classical development process evolves into two complementary processes (Fig. 6): *

One process dedicated to patterns engineering FOR reuse, i.e. identification and specification of the

244

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

An abstract class, called "Figure", represents both composite and simple objects (or leaves). The "Figure" class contains primitive operations such as draw and paint as well as component management operations (access, remove, add a component). The sub-classes (Circle, Text, etc.) implement graphic primitives such as paint or draw in order to color and plot a circle, text, etc. The "CompoundFigure" class also performs the paint and draw operations by recursive calls to the operations of its components: thus, in order to paint a "compound figure", all its "figures" (simple and compound) must be painted (pseudo-code For any figure of components figure.paint). Semi-Formal description: The composite pattern consists of a "Component" class, a "leaf" class, a "composite" class

and a "customer" class. The "component" class defines the common interface of the leaf and composite objects. The "Leaf" class defines the behavior of the leaf objects. The "Composite" class defines the behavior of the composite objects and implements the component management operations. The "Customer" class handles the leaf and composite objects via the Component interface.

Component specific_operation () add (component) remove (component) access ()

Customer

1..* components

Leaf

Composite

specific_operation ()

specific_operation () { } add (component) remove (component) access()

For any c of components c.specific_operation

Fig. 5. Solution.

PIS engineering

From the classic process …

PIS

user specifications

…to 2 new complementary processes

Existing PIS Patterns engineering FOR reuse

Patterns Library

PIS engineering BY reuse

New PIS

Field Analysis user specifications

Fig. 6. New development process.

*

various patterns to use during specification of PIS. This process is based on a field analysis and a study of the existing PIS models in order first to explore the most recurrent problems and then to specify the associated solutions. One other process dedicated to PIS engineering BY reuse of patterns, i.e. specification of PIS using the various patterns identified in the above process. This process, based on user’s requirements, identifies the

problems to resolve, select from the patterns library the patterns which resolve these problems and then considers the proposed solutions. We should note that this new process is recurrent, i.e. the models proposed in the new developed PIS, as a result of the PIS engineering by reuse, supply the patterns engineering process for reuse so to take constantly into account new problems.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

In the next, we are focusing on the first process, that is of patterns engineering For reuse (Section 4). A pattern language is given in Section 5. Highlighting business patterns requires: 1. Identification and comprehension of the problems common to PIS, related to product definition, representation and processing. 2. Specification of various solutions associated to the identified problems. The first step, consisting of identifying problems from the PIS field, is based on the study of existing models in PIS. However, few are the contributions7 that take into account the whole concepts needed in PIS and model the variety of relationships existing between these concepts. Existing proposals for modelling product engineering concepts rather address parts from this field but not the whole [29–31]. Moreover, we noted the absence of a consensus on the concepts managed in PIS, on their formalization and on their behavior. We therefore focus our efforts on constructing a generic framework for PIS, providing a reference model for the field, which can be tailored for the needs of a given PIS environment. This generic framework provides a common terminology and a semantic of the principal concepts and proposes various models to fix these concepts. The reference model thus obtained forms, with the existing PIS models, a basis for exploring the problems frequently occurring in the field. Once identified, these problems are compared to problems treated in existing design patterns catalogues. This allows, on the one hand, to fix the problems already treated in catalogues and, on the other hand, to discover new problems. Once problems are identified and classified, the second step of the engineering pattern process consists of specifying solutions to these problems. Many scenarios can exist: *

*

*

If the problem is already treated in design pattern catalogues, the corresponding existing pattern is thus integrated in our pattern catalogue. If the problem is a refinement (particular case) of a problem already treated in design pattern catalogues, new patterns are thus defined on the basis of the existing patterns treating the general problem. If the problem is complex and can be brought back into problems raised in design pattern catalogues, it is broken down into sub-problems so that they corre-

7 We quote mainly the draft standard STEP (Standard for Exchange of Product model dated) developed by the ISO under the reference ISO10303 whose aim is to develop a standard of product data representation allowing exchange and sharing of these data [31]. We quote also the Object Management Group initiative [28] aiming to develop standard interfaces for PDMs in order to make easier exchange between the various systems.

*

245

spond to the problems treated in the existing patterns and the associated solutions are integrated in the proposed solution. If the problem is new, a new solution is proposed.

Fig. 7 gives a description of the patterns engineering process for reuse, using an UML activity diagram. In the following, the process of patterns engineering is developed. First, the generic framework is presented (Section 4) and then, an overview of the developed business patterns language is given (Section 5).

4. Generic framework for PIS The aim of the generic framework is to fix a terminology and a semantic for the concepts managed in PIS and then to model the variety of relationships existing between these concepts. As we specified in Section 2, PIS are articulated around two axes: product which the purpose of the PIS and processes acting on it during its life cycle. We report particularly on the product axis for which we describe in the sequel the principal concepts. 4.1. Product abstraction levels First of all, we underline that the term product is a general concept whose employment and significance differ from the context. It takes various aspects according to the business considered. Furthermore, many terms referring to the product are used, such as exemplary, generic product, specific product, basic product, etc. Thus, the term product is referred sometimes to virtual objects sometimes with physical objects. To relieve this ambiguity, we define three abstraction levels of the product concept: *

*

*

Production process (manufacturing, support, and maintenance) relates to a physical object; an individualized exemplary of a product: that’s the productexemplary level. For example, in cars production, mypeugeot206
S16. Engineering process, on the other hand, generally relates to the model of product according to which exemplars (with same technological parameters and definition) will be manufactured: it is the objective to be reached; the product generally presented in catalogues: that’s the product-type level. Thus, the model according to which my peugeot 206-S16 was manufactured is the product-type peugeot206
S16. However, in many companies adopting routine design or providing products varying with customer requirements, the development concerns a generic product referring to a set of similar product types and defined with a set of possible options and design

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

246

Existing PIS

Field Analysis

Patterns engineering FOR reuse

PIS engineering BY reuse

Patterns Library

New PIS

Specify solutions Problem already treated in patterns catalogues

Integrate the associated pattern in our catalogue

Identify problems Construct

Problem is refinement of problem already treated in catalogues

reference model Identify

Define new patterns deriving from exiting patterns

problems Analyse existing models

New problem

Problem breakable into subproblems treated in catalogues

Define new solution

Break down the problem into sub-problems which are treated in catalogues

Integrate the patterns associated to the subproblems in our catalogue

Fig. 7. Patterns engineering process, for reuse.

Generic Product Peugeot 206

GP-Name = peugeot 206 engine = thermal or with injection or 4 cylinders or electric color = gree or red or blue

Product-Type

Exemplary-Product

Peugeot 206-S16

My Peugeot 206-S16

PT-name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 litres valves nb = 16 color = green or blue

PE-name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 litres valves nb = 16 color = bleu serial nb. = S16.98.100

Fig. 8. Three levels of peugeot 206.

variants8 (with a multiple configuration that can be reused several times for design of product types): that’s the generic-product level. For example the line of products peugeot206. Exemplary-Product is a physical product whereas Product-Type and Generic-Product are virtual products. Fig. 8 illustrates the concept of three abstraction levels for the product car. 8

Used in the product structure to indicate a co-ordinated set of alternatives in the design which produce a different product, for example, a 4-cylinder auto versus a 6-cylinder auto. Design variants represent sets of variations which evolve in versions consistent with the rest of the product [1].

The distinction we made between the abstraction levels of a product is not simply to raise a terminological ambiguity but especially because we noticed that the knowledge associated with a product is not finally related to the ‘‘same’’ product but to various levels of this product. Thus, in order to organize the various product related knowledge, it is necessary to distinguish these different abstraction levels so to affect the suitable knowledge to the appropriate level. The figure a proposes to model the three abstraction levels. It was built by using twice the ‘‘item-description’’ pattern (Section 3.4). In fact, ‘‘generic-product’’ is a description of ‘‘Product-type’’ and this latter is a description of ‘‘Product-exemplary’’, since the

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

Generic-Product Generic-parameters

Product-Type 1 model

0..*

Type-parameters

Virtual realization

247

Product-Exemplary 1 model

0..*

exemplar-parameters

Physic realization

Fig. 9. Product levels sub-model.

product abandoned [study not OK] studied

Functional

do: feasibility study

[study OK]

do: define

specified

defined

do: develop

do: exploit product retrieved Fig. 10. State diagram of a product-type.

generic-product (respectively product-type) gathers all shared properties of product-types (respectively product-exemplars).

4.2. Knowledge on levels Product Life cycle: A product, whatever is its level (generic, type, exemplary), has a life cycle through which it evolves and consequently passes by various states. Fig. 10 shows a standard life cycle of the product-type. The formalism used is UML state diagrams [32]. The first step in the engineering process is to study the feasibility. The product-type is created in a studied state while the feasibility study is running. When this latter is finished, the product-type is abandoned if it is not feasible or evolving into functional state if it is feasible. In this case, the product is described in terms of expected functions and a definition phase is launched, aiming at refining user’s requirements. When the definition is finished, the product-type evolve into specified state and a development activity is done, aiming at specifying a technical solution and manufacturing methods. Once the development is finished, the product-type become defined and the exploitation (manufacture of exemplars) can start. When the exploitation is finished, the producttype is retrieved from the activity portfolio. We should note that transitions between states in the above diagram are occurring when the activities in the previous state are finished and there is no external event to occur.

Representations of knowledge: During the whole product life cycle and depending on the state of the product, various knowledge is associated with this one to describe it. The state of an object is so function of the knowledge associated to it. This knowledge is supported by various representations forming thus the product model. We distinguish two types of representations: Bill Of Materials (BOM) or configurations and documents. Then, in the ‘‘defined’’ state for example, the producttype can be described by an Engineering bill of material and detail design drawings, part plans, geometric models, etc. In the following, we describe each type of representations. Document: A document is defined as a container for knowledge aiming at describing an object and seized on a support (paper, tape, cassette, disc, microfilm, etc). According to the document finality, we distinguish two types of document. Models aim to define the product (such as CAD drawings) or to control the way in which the associated processes must be carried out (such as manufacturing process routings). Records report the activities results (such as control sheets). A document can be therefore composite or elementary. Such as the case of folders which are composed of a set of documents, gathered in some way in order to treat easily the various knowledge at operational status (such as contractual file, engineering file, manufacturing file, etc.) (Fig. 11). We should note that to represent the concept of composition, the model proposed in Fig. 11 was built by

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

248

Comments

document

{composition}

{finality}

model

• two criteria of classification : one document can be elementary or composite and be model or record. For each criteria, the double classification of document is complete and disjoint.

2..*

record

elementary

• one composite document has as components other documents which can be elementary or composite themselves and model or record.

composite

Fig. 11. Document sub-model.

adapting the ‘‘composite’’ pattern of Gamma (Section 3.4). Bill Of Material: a BOM is defined as a graph structure composed of nodes of same nature and linked by composition9 relationships. It describes the product, at a particular abstraction level, from several points of view, such as: its finality: functional BOM is a hierarchically structured description of the product functions. It is built for the highest product level (generic-product in general) and established during the feasibility study. its definition: engineering BOM is hierarchical representation of the items constituting the product. It is built for the generic-product and producttype and established during development phase. In Fig. 13, we propose a modeling of the recursive items composition. its manufacturing process: manufacturing BOM is a description of successive steps of product elaboration starting from raw materials, parts, sub-assemblies, assemblies until the product itself. It is built for product-type (or product-exemplary) and established during manufacturing preparation phase. its maintenance process: logistic BOM is a tree structure of logistic support elements, organized by maintenance levels. It is built for product-type or product-exemplary.

*

*

*

*

A BOM is thus a recursive composition of technical objects, whereas a technical object is a component of the product. It can be an item, as in the case of organic BOMs (engineering, manufacturing and logistic BOMs), a function as in the case of the functional BOM, a feature in the case of a geometric BOM, etc. In the next, we present the most used technical objects, that is Function and Item). 9

A composition links a composite to its components where the composite is an aggregation of components. Each component describes partially the composite object [33].

Function: The feasibility study describes the product in terms of expected functions to be satisfied by the product. A function is an action of the product or one of its parts expressed in terms of finality [34]. A function can thus be: *

*

an external function expressing an action provided by the product to the environment. It describes what the product does to satisfy a user need and an internal function describing the behavior of product components in terms of how they contribute to realization of external functions.

A function whatever is its nature (internal, external) can be elementary or composite. In the last case, it is only composed of functions of same nature (Fig. 12). We note that functions defined at generic-product level remain available at lower levels. Item: Many terms are used in organic product decomposition, such as component, part, element, subassembly, assembly, sub-system, system, mechanism, etc. Some of these terms correspond to logic criterion of decomposition (component, system, sub-system), some others to material criterion (part, mechanism). An other term often used by the AFNOR10 to describe the product from a management point of view, that is the Item concept which appeared to us suitable for the context of PIS. An item is defined as a constituent of the product, from the most elementary11 component or part (such as a screw) to the product itself, passing by all the intermediate layers of decomposition. We class an item according to criteria. *

Decomposition criterion classifies an item into composite-item (made up in unit) or catalogue-item (supplied such as raw materials, parts, inseparable assemblies, etc).

10 French Association for Standards (Association Fran@aise de NORmalisation). 11 Terminal unit in product decomposition, with no interest to be broken down.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

Comments

Function

2..*

Internal Function (IF)

Composite IF

1..*

1..*

Elementary IF

249

External Function (EF)

Elementary EF

2..*

Composite EF

• two criteria of classification : one function is internal or external. In each case, it can be elementary or composite. • this classification differs from that in figure 11 since one composite function (of external or internal nature) can not be composed of any function but only of function of same nature. The composition classification is made under each nature of function • to each external function, a set of internal functions are associated to express that they contribute to execute the external function

Fig. 12. Function sub-model.

Comments its variant

1..*

Virtual Item

2..*

{variance}

Variant Item

{composition}

Catalogue Item

Constant Item

Composite Item

• two criteria of classification : one item can be catalogue or composite and be variant or constant. For each criteria, the double classification of item is complete and disjoint. • one composite item has as components other items which can be elementary or composite themselves and variant or constant. • the variants of one variant item are items which can be themselves variants or constant.

Comments Physic Item

Catalogue Item

2..*

• one physic item results from a definitive choice between a potential set of variants of a virtual item. No variance has to be managed at physical level. One item can be so catalogue or composite this classification is complete and disjoint.

Composite Item

• one composite item has as components other items which can be elementary or composite themselves. Fig. 13. Item sub-models.

*

Variance criterion classifies an item as a variant-item which has a set of design variants (an engine is a variant item whose variants can be diesel engine, electric engine and thermal engine) or a constant-item, i.e. with no variants. We should note that the variance of an item is relative to the product where it is component, for example in one particular car whose engine can be electric, diesel or thermal, the ‘‘diesel engine’’ is a variant of engine item whereas in an electricity generator the ‘‘diesel engine’’ it is the unique kind of engine.

Just like a product, an item can be perceived at two abstraction levels. One can deal with virtual item and physical item. It can be so described by various representations (documents, BOMs for compositeitems). Thus, virtual products are composed of virtual items and physical products are composed of physical items (Fig. 13). The passage from one generic-product to producttypes and then from one product-type to productexemplars is done according to design variants and optional items. A generic-product has at least two

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

250

Composed

• Optional items are designated graphically by a small circle immediately above the item name. Obligatory Component

Design variant

• Design variants are shown as being children of the same parent variant item, with an arc drawn through all of the options.

Optional Component

• The remaining features with no special notation are all obligatory.

Design variant

Fig. 14. Feature diagram formalism of FODA.

Peugeot 206

The generic product "peugeot 206" is composed of "engine" which has as design variants : "electric”, "thermal” or "4 cylinders". At the definition of producttypes:

4 frame color red color green color blue

radio

• The choice of the variant “electric” for engine implies the choice of the variant “battery” for container.

wheel engine

In case of choice for “4 cylinders” as engine, the components of the engine are then “cylinder” and “valve”.

container electric

petrol tank

• The choice of the variant "4 cylinders” for engine implies the choice of the variant "tank" for container

air conditioner

battery

thermal

4 cylinders 16

cylinder

valve

Fig. 15. Peugeot 206’s BOM.

non-interchangeable12 design variants of the same object in its composition (the choice of one variant is constrained by the choice of variants of other components). A product-type does not present any choice between design variants or is only composed of interchangeable variants. Thus, *

*

The passage from the generic-product to producttypes is made by fixing some variants for each variant item. In the particular case of noninterchangeable design variants, only one design variant is chosen. Furthermore, the choice for one variant of a particular variant item constrains the choice between variants of an other variant item. The passage from the product-type to productexemplars is made by fixing one design variants between a list of interchangeable variants.

Let us consider the example of cars: peugeot 206/ peugeot 206-S16/my peugeot 206-S16. To illustrate this example, we use the feature diagram formalism proposed in FODA [36], described in Fig. 14. In that formalism, at the passage from one level to the lower, the selected optional items and design variants are highlighted in the diagram with boxes. We adapted the formalism by introducing an additional symbol 12 Two objects A and A0 are interchangeable if A0 can be substituted for A without involving evolution of any assembly using A [35].

(double-lined boxes) in order to distinguish the retained items in Product-exemplary level from those in Producttype level (Figs. 15–17). Product view: Based on representations, several views of a product can be defined by the various businesses or actors co-operating in the product development. A view expresses a selective perception of the product, by accentuating special aspects and neglecting others and serves a particular community in the company. A view is thus an extraction of information from the master product model (i.e. from one or more representations) according to certain of its properties. 4.3. Reference model: synthesis Based on the partial models introduced throughout the previous paragraphs, a global model is built by linking these sub-models (Fig. 18). Therefore, some of the above described objects have knowledge in common, we built a super-class to these objects to which we associate this knowledge. Description: It comes out from the descriptions given in Section 4.2 that a product whatever of its level is described by various representations. By representation, we mean documents and Bills Of Materials. *

Each product level is documented by various documents. Product-Exemplary level is essentially

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

251

Peugeot 206-S16

4

air conditioner

frame wheel

engine

color red color green

radio

container

color blue

electric thermal petrol tank

The product-type "peugeot 206-S16" has as color variants : "green" or "blue". The choice of any one of these variants doesn't trouble the composition of the product. All exemplars of peugeot 206-S16 are composed of a "4 cylinders engine", "2 litres cylinder" and 16 "valves", whatever their color.

4 cylinders 16

battery cylinder

valve

Fig. 16. Peugeot 206-S16’s BOM.

My Peugeot 206-S16

4

air conditioner

frame Wheel ref..W789 color green ref..GF147

color red color blue

Radio ref. RD741 engine

container electric thermal

petrol tank ref.. PT123

At the exemplary level (my peugeot 206-S16), the structure is solidified and no choice for variants or options is possible.

battery

4 cylinders ref. CE258 16

cylinder ref. C369

valve ref. V321

Fig. 17. My peugeot 206-S16’s BOM.

*

documented with record-documents. Generic-Product and Product-Type levels are rather documented with model-documents. In the same way, an item some is its nature (virtual or physic) is documented by various documents (such as a plan or a CAD model for a mechanical component). Then, the class ‘‘document’’ can be associated for both items and product levels. We built so a super-class to ‘‘Genericproduct’’, ‘‘Product-Type’’, ‘‘Product-Exemplary’’, ‘‘virtual item’’ and ‘‘physic item’’, named ‘‘documented object’’ to which we associate the class ‘‘document’’ and the associated sub-model. On the other hand, each product level is described by various structures or BOMs. A Bill Of Material is a recursive composition of technical objects which can be items, functions, features, etc. Thus, a BOM is not managed in the PIS as an object, with an own existence; it concretizes the composition relationships between composite objects and related components. It is materialized in the product model by an

*

*

association linking a the structured object, i.e. the object to whom a BOM is associated such as the product, to the root of the corresponding BOM graph which is a composite technical object. Hence: Structural BOMs describing Generic-Product and product-type are based on recursive composition of virtual items. They are modeled by an association between the ‘‘product level’’ class and the ‘‘composite virtual item’’ class, corresponding to the top level of the associated BOM. Since several BOMs based on items are existing, each one is modeled in the item recursive composition model by a particular composition link stereotyped according to its nature (‘‘engineering BOM’’, ‘‘manufacturing BOM’’, etc.). Structural BOMs describing Product-Exemplary are based on physical items. They are modeled by an association between the ‘‘Product-exemplary’’ class and the ‘‘composite physic item’’ class.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

252

0..*

document

2..*

documented Documented Object

GenericProduct 0..*

1 model

0..*

0..* Virtual realization

ProductType

1 model

0..*

0..* Physic realization

model

1..*

its variant

ProductExemplary 0..1

{finality}

0..*

Virtual Item

record

elementary

composite

“engineering BOM” 2..* “manufacturing BOM”

{variance}

Variant Item

{composition}

2..*

Physic Item

{composition}

Constant Item

Composite Item

Catalogue Item 0..*

0..*

Catalogue Item

Composite Item 0..*

« BOM »

« BOM » « BOM » « BOM » Function

2..*

Internal Function (IF)

1..*

1..*

External Function (EF)

2..* « functional BOM »

Composite IF

Elementary IF

Elementary EF

Composite EF 0..*

Fig. 18. PIS reference model.

*

Only Generic-Product is described by functional BOM. This latter is modeled by an association between the ‘‘Generic-Product’’ class and the ‘‘composite external function’’ class.

Analysis: The proposed reference model was built, basing on the hypothesis of three levels of product. It relies then functional BOM to only ‘‘generic-product’’, for example. We highlighted the existence of three product levels in the enterprise but some organizations may not have generic product. In this case, functional BOM is rather associated with ‘‘Product-Type’’. Some other organizations may not manage product-exemplary level. In this case, there is no reason to distinguish physical items. Furthermore, the number and type and BOMs managed is widely varying between organizations (functional BOM and hence functions may not be managed whereas geometric BOM exits for example). Type of documents is also varying. Then, Fig. 18 can be perceived as a possible product model for a PIS based on three levels of product, three BOMs (functional, engineering, manufacturing) and record and model documents. The reference model so obtained is both too general and too specific. It is general because it does not express

specific properties to organizations (for example item property ‘‘resistance’’ for an electronic cards industry). Thus it is not easily used by organizations. On the other hand, it is specific in the mean where it expresses a particular case of three product levels, three BOM types, etc. The aim to build a generic product model, raising all differences due to the luck of a consensus about PIS concepts, is very ambitious. We can only express the variability about these concepts. The Key remaining challenge is so to keep general the reference model, even more general and more complete than the current one, and to give a method to express the variability.

*

*

One solution consists of proposing first a meta-model, too general and then declining various models from this meta-model by instantiating it according to various specificity points. This solution remain restrictive since it fixes in advance the specificity. An alternative solution is to propose first a general model and then to give a method to refine this model based on various patterns, allowing each one to specify one particular variability point. This approach seems more suitable since it is more flexible.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

The retained approach to offer a method for PIS engineering is so to propose a general reference model and then to offer a pattern language.13 That consists of proposing a pattern language which allows to adapt this reference model, according to various variability points, so to fit it into one organization specificity.

5. The pattern language In the proposed reference model (Section 4), we conclude on the impossibility to fit into the generic framework one single model, too general to be used by everyone and too specific to take into account every organization characteristics. The key challenge is to keep generality in the reference framework, by expressing organizations variance, and to give an approach allowing construction of specific models according to the organization preferences. This approach for PIS engineering is made possible by reuse of patterns. It is based on use of a succession of patterns resolving various problems of PIS specification and providing a progressive refinement of models according to the organization specificity. The passage from one pattern to another is carried out according to two mechanisms or links: use link and refinement link. Use link: A pattern B ‘‘uses’’ a pattern A when the solution of pattern A constitutes completely or partially the intention of pattern B, i.e. the problem treated in B is a sub-problem of that in pattern A. For example pattern A is for engineering change process management and pattern B is for engineering change request. Refinement link: A pattern B ‘‘refines’’ a pattern A when the intention of pattern B is a special case of the intention in pattern A, i.e. the problem treated in pattern B can be resolved also by the solution in pattern A. For example pattern A is for BOM construction and pattern B is for functional BOM construction.The proposed approach is thus a succession of business patterns relied by these links. 5.1. Pattern ‘‘variance points’’ As stated before, there is variance between organizations about some points related to product levels, kind of BOMs, document types, etc. The first step in the PIS specification project is, in our opinion, to fix specificity of the organization according to these variance points which constitute the input points of the approach. Name: Variance Points. Classification: Product Pattern.

Intention: Identifying all variance points in the organization in order to fix them so to associate the adequate knowledge. Motivation: Some organizations have single types of products, others have also lines of products so that they manage generic and types of products. In both these cases, product exemplars can be or not managed, according to the criticality of the exemplars and the after sale services (thus in aerospace domain, every plane exemplar is managed to keep trace on manufacturing conditions and maintenance changes occurring during its life whereas in mass production such as of pencils manufacturing, no exemplars are managed). Furthermore, the type and the number of BOMs used are also varying from one organization to an other. In organizations all managing Product types, some of them have only one structural BOM whereas others distinguish technical BOM, manufacturing BOM, logistic BOM, etc. Moreover, number and types of documents are also varying from one organization to another. Solution: 1. Fix the number and type of product levels (generic, type, exemplar). For that purpose, apply the pattern ‘‘Product Levels’’ 2. Fix the type of applied BOMs For that purpose, apply the pattern ‘‘Applied BOMs’’ 3. Associate the applied BOMs to the product For that purpose, apply the pattern ‘‘Associate BOMs To Product’’ 4. Fix the type of applied documents For that purpose, apply the pattern ‘‘Applied Documents’’ 5. Associate the applied documents to the product For that purpose, apply the pattern ‘‘Associate Documents To Product’’ Assess: In solution of pattern ‘‘Variance Points’’, it is suggested to fix the product levels, to fix the applied BOMs, etc. The immediate patterns have hence the intention to provide a guide to fix each of these points (Fig. 19). We only develop the pattern ‘‘Products Levels’’. 5.2. Pattern ‘‘product levels’’ Name: Product levels. Classification: Product Pattern. Intention: There are three abstraction levels of product: *

13

A pattern language is a set of patterns relied with links of various natures such as use, extension/refinement and alternative links. These links were developed in [37].

253

*

Exemplary: physical object resulting from manufacturing process, Product-type: the theoretical model according to which exemplars are manufactured,

254

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

Pattern « Product Levels » “use”

Pattern « Applied BOMs » “use” Pattern « Associate BOMs To Product »

“use” Pattern « Variance Points » “use”

Pattern « Applied Documents »

“use”

Pattern « Associate Documents To Product »

Fig. 19. Fixing variance points.

Generic Product Peugeot 206 GP-Name = peugeot 206 engine = thermal, with injection or 4 cylinders color = green or red or blue

Product-Type Peugeot 206-S16 PT-Name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 liters valve nb = 16 color = green or blue

Product-Exemplary my Peugeot 206-S16 PE-Name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 liters valve nb = 16 color = blue serial number = S16.98.100

Fig. 20. Three levels of peugeot 206.

Generic product: a theoretical model including all possible options and design variants, according to which the definition of a particular product-type is declined by a particular choice of options and variants. The pattern ‘‘Product Levels’’ allows identification of the number of product levels managed in the organization and proposes solution to represent them. Motivation: Let us take the following example for the product ‘‘Car’’ (Fig. 20). This product takes various aspects and is described by different knowledge according to the business dealing with. We distinguish three aspects:

*

*

*

*

The exemplary-product: the product which is delivered to the customer, such as my peugeot 206 S16. The product type: the model defined by the engineering services and according to which various exemplars are manufactured in production units, such as the peugeot 206 S16. It is the product presented in the catalogue and according to which the customer places a buying order. The generic product: a line of product types sharing many characteristics and deriving by some options or

variants in their structure. It is the product developed by engineering services and according to which they derive various configurations according to different customer requirements. The line peugeot 206 is a generic product. The entity Generic-Product has an abstraction level higher than the entity Product-Type. This latter is higher than Product-Exemplary. Generic and type levels are virtual products whereas exemplary level corresponds to a physical product. These levels of product are distinguished because the knowledge associated with the product is varying according to the level. In order to organize this knowledge, it is necessary to distinguish these levels so to affect the suitable knowledge to the appropriate level. Solution: An organization has always a product type (for example: peugeot 206-S16). To identify the other levels, one must answer to the following questions: 1. do you manage physical exemplars? Case a: yes. There is the levels Product-type and Product-exemplary Case b: no. There is the level Product-Type

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

Pattern «Three Levels»

Product-Type

Product-Exemplary

Peugeot 206-S16

my Peugeot 206-S16

“use” Pattern « Product Levels »

“use”

Pattern «Two Levels»

“use” Pattern «One Level»

Fig. 21. Product levels.

255

PT-Name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 liters valve nb = 16 color = green or blue

PE-Name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 liters valvenb = 16 color = blue serial number = S16.98.100

Fig. 22. Two levels of peugeot 206.

2. does the product type forms a part of a product-line? Case c: yes. There is the levels Generic-Product and Product-type Case d: no. There is the level Product-type General structure: 3. if case a and c are true: There is three levels; generic, type, exemplar. Apply pattern ‘‘Three Levels’’ 4. if case a and d are true: There is two levels; type, exemplar. Apply pattern ‘‘Two Levels’’ 5. if case b and c are true: There is two levels; generic, type. Apply pattern ‘‘Two Levels’’ 6. if case b and d are true: There is one level; type. Apply pattern ‘‘One Level’’ Assess: The solution in pattern ‘‘Product Levels’’ suggests to use various patterns to represent one, two or three levels (Fig. 21). In the following, we describe the patterns ‘‘Two Levels’’ and ‘‘Three Levels’’.

5.3. Pattern ‘‘two levels’ Name: Two levels Classification: Product pattern. Intention: this pattern allows representing the product concept in 2 abstraction levels in order, first to partition knowledge between these levels (common properties in higher level and individual properties in lower level) and second to define relations between the levels so to allow propagation of properties values between levels. This pattern can be applied for representing Generic-product and Product-type levels as well as Product-Type and Product-Exemplary levels. Motivation: Let us consider the example for the product Car. We illustrate the particular case of the two levels: Product-Type and Product-Exemplary (Fig. 22). Knowledge associated with these 2 entities (ProductType PT, Product-Exemplary PE) depends on the abstraction level. The entity Product-Type has an abstraction level higher than the entity ProductExemplary. Otherwise, the knowledge described for each of these entities is of two types:

Entity properties: An entity takes a value for each one of its properties. For example, properties engine = 4 cylinders for the product-type Peugeot 206-S16 and serial number = S16.98.100 or color = blue for the exemplary my Peugeot 206-S16. We notice that a property value existing at a certain abstraction level must be visible at a lower level. Then, the property engine of the Product-Type: Peugeot 206S16 having for value 4 cylinders, is also visible in the Product-Exemplary: my Peugeot 206-S16. Constraints: Expressed at a certain abstraction level and bearing on values of lower level properties. For example, the constraint color ¼ greenorblue; expressed for the Product-Type: Peugeot 206-S16, constrains the value of the property color of the Product-Exemplary: my Peugeot 206-S16 (color = blue). In Fig. 23, we propose a class diagram and an instance diagram that partially represent the example above. Associations allow to link every exemplary to its product-type. peugeot206-S16 (respectively my peugeot206-S16) is an instance of the ‘‘Product-Type’’ class (respectively ‘‘Exemplary-206-S16’’ class). The properties of a level remain visible at the lower level by defining consultation methods allowing to propagate a value through associations. Let us take the example of engine property: when one requests to my peugeot206-S16 its engine, it executes the method: Engine? (), defined in its class ‘‘Exemplary-206-S16’’. This method returns the value of the engine attribute from the model of the ‘‘exemplary 206-S16’’ (pseudocode return model.Engine?), which is ‘‘Type-206’’ (through the model role of the association between an exemplary and its type). In the example, the value of that attribute is 4 cylinders. However, the preceding modeling does not allow refining constraints on a property at the ProductExemplary level. In the present example, the color property is constrained at type level (color of peugeot206-S16: blue or green). An other type of product such as peugeot 206-1,1 L XR for example, can only have the colors: green or red. Thus, the preceding modeling does not allow illustrating this intermediate layer of constraint on the color, according to the type of product. Then we add the

256

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

Class diagram

Type-206

Exemplary-206-S16

PT-Name engine : enum (thermal, with injection, 4cylinders)

1

0..*

model

Physic realization

property

serial number color : enum (green, blue)

constraint

Engine? () { }

return model .engine

peugeot206-S16 :Type-206

Instance diagram

my peugeot206-S16 : Exemplary-206-S16

PT-Name = peugeot206S16 engine = 4 cylinders

serial number = S16.98.100 color = blue

Fig. 23. Properties and constraints.

Type-206

Exemplary-206 1

PT-Name engine : enum (thermal, with injection, 4cylinders)

the constraint on the color is refined between the genericproduct "Peugeot 206" (color = green or red or blue) and the product-type "peugeot 206-1,1 LXR" (color = green or red).

model

0..* Physic realization

serial number color : enum (green, red blue)

Exemplary-206-S16

Exemplary-206-1,1 L XR color : enum (green, red)

color : enum (green, blue)

my peugeot206-1,1 LXR : Exemplary-206-1,1 LXR

my peugeot206-S16 : Exemplary-206-S16

serial number = LXR.98.10 color = green

serial number = S16.99.15 color = blue

Fig. 24. Constraint refining.

abstract class ‘‘Exemplary-206’’ whose the class ‘‘Exemplary-206-S16’’ is a subclass. It is thus possible to define other subclasses (‘‘Exemplary-206-1,1 L XR’’ for example) holding different constraints––see Fig. 24. Solution: 1. A company organizes its activities around two product abstraction levels. There exist two abstract classes (Fig. 25). Product higher level ‘‘PHL’’, holding common properties to lower level products deriving from it and a set of possible values for some properties. Product lower level ‘‘PLL’’, holding specific properties of lower level products associated to one higher level product and a fixed value of some properties. Two scenarios can exist: ‘‘PHL’’ is a generic-product and ‘‘PLL’’ a product-type or ‘‘PHL’’ is a product-type and ‘‘PLL’’ a product-exemplary.

PHL common parameters

PLL 1 model

0..*

specific parameters

realization

Fig. 25. Two abstraction levels of product.

2. When the company decides to create a new Product Higher Level (for example a new generic-product), let us phl1. That corresponds to the creation of a new set of products (for example line of cars ‘‘peugeot 206’’) (Fig. 26), sharing common characteristics. Phl1 is then an instance of the ‘‘PHL’’ class. That results in the object phl1:PHL. With the creation of a new set of products phl1, there will be probably various lower level products deriving from the new set phl1 (for example various product-types). One then creates a concrete class for all lower products resulting from phl1 (for example

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

PHL

PLL

common parameters

specific parameters

1 model

0..*

257

realization

phl 1: PHL

PLL (phl 1)

common properties to phl 1 lower level products

specific properties to phl 1 lower level products

creation of a new PHL, i.e. phl1 (for example a new generic-product peugeot206), implies probably creation of various lower level products relating to phl1 (various product-types of peugeot 206).

Fig. 26. Creation of a new Product Higher Level (phl1).

PHL

PLL

common parameters

1

0..*

model

specific parameters

realization

phl 2: PHL

PLL (phl 2)

common properties to phl 2 lower level products

specific properties to phl 2 lower level products

phl 1: PHL

PLL (phl 1)

common properties to phl 1 lower level products

specific properties to phl 1 lower level products

Fig. 27. Creation of two higher level products (phl1 & phl2).

Generic Product

Product-Type

Peugeot 206

Product-Exemplary my Peugeot 206-S16

Peugeot 206-S16

GP-Name = peugeot 206 engine = thermal, with injection or 4 cylinders color = green or red or blue

PT-Name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 liters valve nb = 16 color = green or blue

PE-Name = peugeot 206-S16 engine = 4 cylinders cylinder = 2 liters valve nb = 16 color = blue serial number = S16.98.100

Fig. 28. Three levels of peugeot 206.

product-types of peugeot 206), let’s ‘‘PLL (phl1)’’. This class contains specific properties to phl1 lower level products Assess: any creation of a new higher level product generates one instance of the class PHL and one subclass of the class PLL (Fig. 27). We should note that in the proposed solution, we deal with a partition of the class ‘‘PLL’’. In fact, for each instance of ‘‘PHL’’ class (peugeot 206 for example), there exist a sub-class of ‘‘PLL’’ associated to this instance to

represent all lower level products raising from that instance of higher level product (for example Typepeugeot 206, for all product types in the line peugeot 206). Thus, the population of ‘‘PLL’’ class is partitioned into sub-classes. This partition is controlled by an inheritance link. In [27], this concept was largely discussed. 5.4. Pattern ‘‘three levels of product’’ Name: Three levels. Classification: Product pattern.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

258

Intention: This pattern allows representing the product concept in three abstraction levels in order, first to partition knowledge between these levels (common properties in higher level and individual properties in lower level) and second to define relations between the

Generic-Product

Product-Type

GP-Name

1 model

0..* virtual realization

PT-Name launching date

Gp1 : generic-Product

Product-Type (gp1)

GP-Name = gp1

Product-Type (gp1)-Name

Fig. 29. First application of pattern ‘‘two levels of product’’.

levels so to allow propagation of properties values between levels (Fig. 28). Motivation: We consider the example of the product Car. We distinguish three levels of this product: Knowledge associated with these three entities (Generic-Product GP, Product-Type PT, Product-Exemplary PE) depends on the abstraction level. The entity Generic-Product has an abstraction level higher than the entity Product-Type. This latter is itself higher than Product-Exemplary. Solution: A company organizes its activities around three product abstraction levels: The ‘‘Generic-Product’’ level, holding the properties of generic products (such as GP-name). The ‘‘Product-Type’’ level, holding the properties of the types of products, resulting from various generic products (such as PT-Name, launching-date). The ‘‘Product-Exemplary’’ level, holding the properties of the exemplars relating to various types

Exemplary-Type (gp1)

Product-Type (gp1) Product-Type (gp1)-Name

1 model

Parameter : enum (a, b, c)

0..* physic realization

Exemplary (pt1-gp1)

Pt1-gp1 : Product-Type (gp1)

parameter : enum (a, b)

Product-Type (gp1)-Name = pt1-gp1

Fig. 30. Second application of pattern ‘‘two levels of product’’.

Generic-Product GP-Name

Product-Type 1 model

gp1 : Generic-Product

PT-Name launching date

0..* Virtual realization

Product-Type (gp1)

Exemplary-Type (gp1) 1

GP-Name = gp1

Product-Type(gp1)-Name

model

0..* Physic realization

color : enum (green, red, blue)

pt1-gp1 : Product-Type(gp1)

Exemplary(pt1-gp1)

Product-Type(gp1)-Name = pt1-gp1

color : enum (green, blue)

my pt1-gp1: Exemplary(pt1-gp1) color = blue

Fig. 31. Three abstraction levels modeling.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

“use”

Pattern «Three Levels»

259

Pattern «Two Levels»

Fig. 32. Use of pattern ‘‘two levels of product’’.

“use” Pattern «Product Levels» “use”

“use”

Pattern «Three Levels» Pattern «Two Levels»

“use” Pattern «One Level»

Pattern «Construct BOM» “use” Pattern «Applied BOMs »

“use”

“use”

“refine” Pattern «BOM With Variants»

“refine”

“use” Pattern «BOM With Pattern «Variance Points»

Pattern «Associate

“use”

Existential Dependence»

BOMs To Product » “use” Pattern «Applied Documents » “use” Pattern «Associate Documents To Product»

Fig. 33. Overview of the pattern language.

of products (such as serial-number, manufacturingdate). Generic-Product level is higher than ProductType level, which one is higher than Product-Exemplary level. 1. Apply the pattern ‘‘Two Levels’’ to the ‘‘Genericproduct’’ as the ‘‘PHL’’ and the ‘‘Product-Type’’ as the ‘‘PLL’’. An instance of the ‘‘PHL’’ class is, in this case, a new generic product (corresponding to the creation of a new product line) that we named gp1 (for example the generic product: peugeot206). The model (Fig. 29) is obtained: 2. Apply again the pattern ‘‘Two Levels’’ to the ‘‘Product-Type (gp1)’’ as the ‘‘PHL’’ and the exemplars of this latter, let us ‘‘Exemplary-Type (gp1)’’ as the ‘‘PLL’’. An instance of the PHL class is, in this case, a new type of product in the line of products gp1 (for example the type peugeot 206-S16 in the line of peugeot 206 products) that we named pt1-gp1. The model (Fig. 30) is obtained: General structure: The final model obtained by joining the two models above is the following (Fig. 31):

my pt1-gp1 is an individual exemplar manufactured in the organization, delivered for me. Assess (Fig. 32): 5.5. Overview on the pattern language In the following (Fig. 33) we give, in a use-case diagram, an overview of the whole business pattern language developed for product modeling.

6. Conclusion Reuse, already efficient in software engineering, is also interesting for PIS engineering. This approach evolves the classical development process into two complementary processes: one dedicated to patterns engineering FOR reuse (identification and specification of patterns) and one other dedicated to PIS engineering BY reuse of patterns. A special interest was given to the first process, i.e. the By reuse process. For that purpose, the first step consisted of identifying the most recurrent problems in PIS field. This exploration is based on the study of existing PIS models but also on a field analysis aiming at constructing a reference model for PIS. After identifying

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

260

process constitutes hence the specification of the BY reuse process.

problems, the second step consisted of specifying solutions to the problems discussed above, basing partially on solutions proposed in existing design patterns catalogues. An overview of the developed business pattern language is given. This pattern language is actually under test and validation by our

Appendix A. UML notation

State Diagram

Class diagram Class

Initial state

Association Binding

A property operation

event [Guard condition]

State

object

B 1..*

b:B property = value

do: operation

Multiplicity

Generalization

C

D

Final state

Composition

transition

Activity Diagram

Use-Case Diagram

Initial state

Actor fires the use case A C contains the behaviour described in A

event [Guard condition]

activity

«extend »

activity

Acteur

Use case A

activity

B extends the behaviour described in A Final state

« use »

Use case C

transition with exclusive conditions

Use case B

Fig. A1.

industrial partner. Some of the proposed patterns have been used to specify the extension of an existing PDM system in the domain of mechanical engineering to take into account electronic parts of the products. Extensions of the current language for a complete description of the PIS domain including versioning mechanisms, passage between product levels mechanisms, etc. is under progress. It has also to be extended to take into account process modeling. With term, once business patterns are identified and specified, we shall focus on the definition of associated software patterns. After, once the pattern language is completely specified, the BY reuse process for PIS engineering will consist simply of applying this language. The FOR reuse

References [1] CIMdata Inc. Product data management: the definition. An introduction to concepts, benefits, and terminology (http:// www.cimdata.com/), 1997. [2] Waite EJ. In: Kosanke K, Nell JG, editors. AIT—advanced information technology for design and manufacture. Proceedings of the ICEIMT’97 International Conference on Enterprise Integration and Modeling Technology, 1997. [3] RISESTEP. Enterprise wide standard access to step distributed databases. Esprit 4 Project, 1996–1998. [4] OPAL. Integrated information and process management in manufacturing engineering. Esprit 4 Project, 1997. [5] Poulin JS. Populating software repositories: incentives and domain specific software. J Systems Software, 1995;30:187–99. [6] Wilson DA, Rosenstein LS, Shafer D. Programming with MacApp. Reading, MA: Addison-Wesley, 1990.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261 [7] Fukanaga A, Pree W, Kimura T. Functions as data objects in a data flow based visual language. ACM Computer Science Conference, Indianapolis, 1993. [8] Alexander C, Ishikawa S, Silverstein M, Jacobson M, FriksdhlKing I, Angel S. A pattern language. New York: Oxford University Press, 1977. [9] Gamma E, Helm R, Johnson R, Vlissides J. Design patterns: elements of reusable object oriented software. Reading, MA: Addison-Wesley Publishing Company, 1995. [10] Beck K, Cunningham W. Using pattern languages for objectoriented programs, Norman MEYROWITZ, OOPSLA’87, 1987. [11] Coad P. Object-oriented patterns. Commun ACM, 1992;35(9). [12] Harrington HJ. Business process improvement—the breakthrough strategy for total quality, productivity, and competitiveness. New York: McGraw-Hill Inc, 1991. [13] Xue D, Yadav S, Norrie DH. Knowledge base and database representation for intelligent concurrent design. Comput Aided Des J 1999;131–45. [14] Kimura F, Suzuki H. Representing background information for product description to support product development process. Ann CIRP Annals 1995;44(1):113–6. [15] Ranta M, M.antyl.a M, Umeda Y, Tomiyama T. Integration of functional and feature-based product modeling—the IMS/GNOSIS experience. Comput-Aided Des 1996;28(5):371–81. [16] Rosenman MA, Gero JS. Modelling multiple views of design objects in a collaborative CAD environment. Comput Aided Des 1996;28(3):193–205. [17] AMICE. CIMOSA: Open System Architecture for CIM, 2nd extended and revised version. Berlin: Springer, 1993. [18] Williams TJ. The Perdue enterprise reference architecture. Perdue Laboratory for Applied Industrial Control, Perdue University, West Lafayette, IN, USA, March 16, 1992. [19] Fox MS, Chionglo JF, Fadel FG. A common-sense model of the enterprise. Proceedings of the Industrial Engineering Research Conference, 1993. [20] Ladet P, Vernadat F. The dimensions of integrated manufacturing systems engineering. Integrated manufacturing systems engineering. London: Chapman & Hall, 1995. [21] Vernadat F. Enterprise modelling and integration: principles and applications. London: Chapman & Hall, 1996. [22] El Mhamedi A, Lerch C, Marier S, Sonntag M, Vernadat F, Int!egration des activit!es non structur!ees das la mod!elisation des syst"emes de production ACNOS. Final report of the project ACNOS—DSPT 8 en productique du MENESR, 1997 (in French).

261

[23] Jacobson I, Ericsson M, Jacobson A. The object advantage: business process reengineering with object technology. Reading, MA: Addison Wesley, 1995. [24] Coad D, North P, Mayfield M. Object models—strategies, patterns and applications. Yourdon Press Computing Series, 1996. [25] Fowler M. Analysis patterns: reusable object models. Reading MA: Addison-Wesley, 1997. [26] Gamma E, Helm R, Johnson R, Vlissides J. Design patterns: elements of object oriented software architecture. Reading, MA: Addison-Wesley, 1994. [27] Dahchour M. Formalizing materialization using a metaclass approach. In: Proceedings of CASSE’98, 1998. [28] OMG, Product data management enablers–request for proposal. Object Management Group document, 1997. [29] Van Veen EA. Modelling product structures by generic billsof-material. Ph.D. thesis, Eindhoven University of Technology, 1991. [30] Peltonen H, M.annist.o T, Alho K, Sulonen R, Product configurations—an application for prototype object approach. Proceedings of the Eighth ECOOP Conference, Lecture Notes in Computer Science, vol. 821. Berlin: Springer, 1994. p. 513–34. [31] IMS/Gnosis Consortium. Report on the IMS/GNOSIS test case: configuration systems for knowledge systematization, 1995. [32] Rumbaugh J, Jacobson I, Booch G. Unified modeling language reference manual. Reading, MA: Addison Wesley, 1997, ISBN: 0-201-30998-X. [33] Magnan M, Oussalah C. Objets et composition. In: C. Oussalah, editor. ‘‘Ingenierie Objet—concepts et techniques’’, InterEditions, 1997 [in French]. [34] AFNOR. NF EN 1325—Vocabulaire du management de la valeur, de l’analyse de la valeur et de l’analyse fonctionnelle— Partie 1: analyse de la valeur et analyse fonctionnelle. Afnor, Paris, November 1996 [in French]. [35] Maurino M. La gestion des donnees techniques—technologie du concurrent engineering. Paris: Masson, 1993 [in French]. [36] Kang KC, Cohen SG, Hess JA, Novak WE, Spencer Peterson A. Feature-oriented domain analysis (FODA) feasibility study. Technical Report AD-A235 785, Carnegie-Mellon University, Software Engineering Institute, 1990 [37] Rieu D, Giraudin JP, Saint-Marcel C, Front-Conte A. Des operations et des relations pour les patrons de conception. In: Proceedings of Inforsid 1999, La Garde, France, 1–4 Juin 1999 [in French].