A Product Model Enabling SMEs to Co-operate in a Distribute Engineering Environment Franca Giannini, Marina Monti Institute for the Applied Mathematics – CNR, via de Marini 6, 16149 Genova Italy Tel. +39 010 64751 Fax +39 010 6475660 email: giannini(monti)@ima.ge.cnr.it

Domenico Biondi Democenter, viale Virgilio 55, 41100 Modena Italy Tel +39 059 848810 Fax +39 059 848630 email: [email protected]

Flavio Bonfatti, Paola Daniela Monari Dept. of Engineering Sciences, University of Modena, via Campi 213/B, 41100 Modena Italy Tel +39 059 376732 Fax +39 059 376799 email: [email protected]

Abstract The paper illustrates a product model to support co-design activities developed within the Esprit Project EP25360 COWORK (COncurrent project development IT tools for small-medium enterprises netWORKs) The idea of co-design between SMEs arises from the need of putting together the competencies that the participating nodes can offer in order to afford a design project that goes beyond the possibilities of the single node. Each partner develops a part of the whole project and exchanges with the other partners the only information of common interest, thus preserving its specific know-how. The paper focuses the Product Manager module, specifically devoted to manage the knowledge that is strictly necessary to support the co-design activities of the single node within the network: hence, the Product Manager includes all and only those concepts pertaining to the description of the product whose design is in charge of the node.

1.

Introduction

Today SMEs operate in a market characterised by strong economic pressures and to short time-tomarket and to maintain a high quality level since the beginning have became the main success factors Generally, all manufacturing SMEs, and particularly enterprises working in the mechanical sector, need to frequently innovate themselves, both to create new products and to enhance the quality of the existing ones: the development of a new product can not only be reduced to find the appropriate configuration of standard components already existing on the market, but very often requires the development of new ones, possibly not only for the modification of the physical interfaces but also in functional terms. Since SMEs often do not have the

complete knowledge for developing all the components needed for their products, they have to outsource the development of specific parts, starting in this way a co-operation with other enterprises working in the same industrial sector, in order to achieve a market objective that otherwise could be out of reach. Often the co-operation implies not a simple made-to-order development [1] but a real collaboration among the companies in the definition of the new product. It is then possible to say that these enterprises give rise to special type of Virtual Enterprise (VE) [2], in which each company maintains the greatest flexibility and business independence [3]. To be fast in the establishment of such VE is thus a key issue for being successful in the market, as well as to define the proper collaboration methodology: to achieve this aim it is fundamental to have proper IT tools supporting companies during all the phases of a VE’s life cycle, starting from the identification of the most suitable partner, but also during the contract definition and the product specification. Despite of the investment made in these last years, both in the research and the industrial field, currently the market still presents a lack of IT tools able to support SMEs in co-design activities in particular at a cost sustainable by small enterprises; there are some IT instruments whose aim is to support the organisation of engineering activities, partially targeted to shorten engineering time but their characteristics of use are absolutely incompatible with SME procedures. In addition, most of PDM systems are mainly devoted to support process organisation and product data management internal to a specific company, possibly geographically distributed, but no real support for external negotiation is really offered. This paper describes a software tool aimed at enabling SMEs, working in the mechanical sector, to co-operate in a distributed engineering environment. The tool is the result of the Esprit Project 25360

COWORK (COncurrent project development IT tools for small medium enterprises netWORKs) [4]. In particular the focus will be on the Standardised Product Model and on the software module implementing the model itself, i.e. the Product Manager: it will be described how it handles the product specification and the negotiation on technical data. The paper is organised as follows: in Section 2 the user requirements for a product manager gathered at the beginning of the COWORK project will be illustrated. Section 3 gives an overview of the COWORK methodology and system. Section 4 describes the developed Product Manager in details. Section 5 gives an overview of the process of validation of the developed tool. Finally, Section 6 ends the paper with the conclusions.

2. The user requirements framework A good system analysis begins by capturing the requirements of an application [5] , therefore with the aim of developing a Product Manager specifically oriented to support users in their co-design activities, the first fundamental step has been to build a realistic user requirements framework; guided interviews have been proposed to users, i.e. SMEs from Italy, Spain and Germany, working in the mechanical sector: they had to explain the details about their current codesign activities, such as information exchange, constraints of that exchange, IT tools used in technical office and so on. Users were requested to specify the information on the basis of actual examples of the company, such as the current aspects of design activities, in particular for the paper topic, with regard to the management of the product data [6]. In a successive analysis phase, the end user requirements have been homogenised, and requisites for the different software modules have been established. Additionally, several discussions have been held between the end users, the intermediate users and innovators of each country to identify the most relevant needs concerning the design processes. The user requirements collection has been carried out by national networks, due, among other reasons, to the ease of using the same language and the closeness (not only geographical closeness).

2.1 Requirements on Generic IT tools First of all the framework of the IT tools has been analysed: the objective was to have a clear understanding about aspects such as the operating system in which the COWORK software would have to work, the kind of computer generated documents that COWORK would have to manage and other similar questions.

With regard to the hardware, it came out that the most part of the companies use Personal Computers (PCs) for design activities; the operating system used by the designers was mostly Windows NT, and moreover, all of them have expressed Windows NT as preferred operating system for the future. One important aspect about the CAD programs used by the companies is that the end users have different types of CAD, and moreover they are often changing their CAD system. However, this heterogeneity is not so critical, because the end users have remarked that the information exchanged, concerning geometrical aspects, are usually 2D drawings in IGES or “dxf” formats. The users remarked that CAD systems are intended as a support tool to perform specific, often sophisticated, design activities: much knowledge on design aspects remains outside the CAD system, and it is very often on paper support.

2.2 The co-design scenario The design programs currently used in the technical offices of the end users have also been analysed with the objective of knowing what kind of information they interchange during a design project. As to the product codification, the enterprises use different modalities to codify their projects, purchased parts and parts that are co-designed. Thus, some enterprises apply a ‘self explaining code’ or a ‘self meaning code’ to codify the product resulting from the internal design activity, others use automatic means for producing incremental code number. From this information, it can be seen the necessity to communicate, receive and maintain codes related to co-designed parts and designs. A further point regards information that is presently used to describe the product. The information about the product resulting from the internal design activity is often the following: CAD files (2D and 3D) and tables, paper 2D-drawings (generated by CAD but not only) and documents regarding technical information. As regards the paper drawings and sketches, information about their place and dimensional characteristics are kept. Always the R&D office (which produces the design) generates a bill-of-material and then communicates it to the commercial office. Further maintained information relative to a part could be its name, its amount in the assembly, short description, material, treatments and remarks. As regards the final product, the main characteristics are also described into the commercial catalogues. The information about the purchased parts is often linked to the technical and functional characteristics reported in commercial catalogues. Sometimes, records about the purchased parts are stored; in those records the description of the part (type,dimensions,…) and information about the

supplier are kept. The commercial and purchaser departments take track of the parts and their relative supplier as well. The information about the parts co-designed by lower level co-designers are paper 2D drawings and sketches made by the enterprise itself as contractor and communicated to the lower level partners. These sketches are general designs in which specifications, tolerances and requirements are reported. Sometimes, files containing this information are exchanged and maintained. Further information regards the codesigner (information about the enterprise). Some enterprises adopt their own conventions to handle the product data files but without efficient results. Generally, a proper computer-supported system to manage the product data is not used by any user. An essential difference between a distributed design process and a centralised design process is that in the latter case the involved enterprises do not have a total visibility about the primary object of the design activity, that is, the detailed product model. They have visibility only about the information needed to each enterprise to execute at best its own co-design activities. This occurs because each enterprise feels proprietary of its own expertise, and therefore it does not intend to make its knowledge fully accessible to others. In fact, a typical situation is the one in which the same enterprise is able to take part in various projects of co-design, from time to time with different enterprise networks. It is unbelievable that each time an enterprise network arises, which generally will last only for a specific project, all the component designers transfer to the customer the total knowledge about its own part. Since the co-design refers to a limited set of exchangeable information, it is important that such information is: ü Structured, and thus not ambiguous

in its old projects based on customer specifications. An example has been observed with one of the users: when a customisation is required, two parts are involved: the equipment that uses the crane jib (customer activity) and the crane jib itself, like shown in Figure 1.The relationship among the company and the customer is very simple and the times are not too long. Mobile digger

Crane

Figure 1 An example of product customization Design of a new project : another case presents a contractor (Main Contractor), some co-designers, and several suppliers. This can occur when marketing analysis shows the advantage to design a new product family, see Figure 2. During the design, the codesigners and the contractor have a deep interaction.

Crane

Cylinder

Valve

Distributor

ü

Exchanged in the right way and negotiable in time, until a shared version is reached As the information visibility, we can focus on each co-design group. It is composed by an enterprise, its customer (that can be in turn a co-designer for an upper level customer) and the involved co-designers carrying out design activities assigned by the enterprise in discourse. The co-design group should manage ü the information of interest for the enterprise and for its customer ü the information of interest for the enterprise and each of its lower level partners Considering the cases found at the user sites, some typical partnerships and network structures have been identified: Customisation of an existing product : The first network has only two nodes: customer node and codesigner node. The co-designer has to make changes

Figure 2 An example of design of a new product Entrustment of the design and production of a product: sometimes, in a network it occurs that a codesigner entrusts the design and the production of a product to a sub-contractor. This can be due to lack of time or peculiarity aspects of the product that has to be produced. An example has been observed, with one company in the role of co-designer, which entrusts the production of a cylinder to subcontractors, like illustrated in Figure 3.

Crane

Internal co-design of one-of-a-kind equipment: some enterprises put in practice the internal co-design in addition to the external co-design. Different activities are determined; some of them are internal while other are external, that is to say, in charge to different enterprises. Each activity has a certain freedom degree about the design of the part in charge. An example of this type of co-design comes from a typical product structure of a machine tool, where the required information for each co-designer is linked to a node of the product structure, see Figure 5. This will be the internal information for that co-designer. A typical case of a machine tool consists of a set of fixed modules (X, Y, Z-axes), peripherals (Enclosure, Tool Magazine...) and a set of complements. It is quite usual that a different co-designer designs each component of a machine (X-axis, Y-axis, enclosure, etc.)

Excavator

Cylinder

Cylinder

Figure 3 An example of entrustment of the product design and production Design and production of one-of-a-kind product: some enterprises are one-of-a-kind producers. Thus, their network has a customer, which generally gives only functional requirements, and several codesigners and suppliers. An example is represented in Figure 4 : a company which designs and produces jibs crane, and a company which designs and produces hydraulic cylinders, represent two co-designers. Two suppliers, who operate following the Main Contractor requirements, are represented as switchboard and bogie producers. Interactions with the customer can occur when it wants to modify given requirements or to indicate new ones (i.e. changes regarding speed feed machine, mast shape and so on). Railway lines

Drilling machine

Crane

Cylinder 2 Switchboard

Bogie

…

Figure 4 An example of design and production of one-of-a-kind product

Machine-Tool

X-axis

Y-axis

Z-axis

Enclosure

Figure 5 An example of Internal co-design of one-of-a-kind product

2.3 Data exchanged The detail level of the technical product description that a co-designer must give to its upper level co-designer depends on the contract the two enterprises establish to regulate their mutual collaboration. A typical situation occurs when the involved co-designer is an engineering firm: in this case, the result of its work, what the upper-level codesigner pays for, is the whole design documentation of the assigned part. On the contrary, when the codesigner is a manufacturing firm, the result of its work is a number of manufactured pieces, whose features have been agreed in a tight interaction with the upper level co-designer. The more common situation is the latter. In this case, a relevant problem is how to accomplish the project successfully without exchanging the whole product knowledge among partners. Thus, public information in the network on technical aspects is seen as a set of technical requirements, which describe and indicate the main characteristics of the project to design. These requirements are matter of discussions between the network involved partners, and their fulfilment ensures the correctness of the manufactured part.

Generally, the exchanged technical information has different versions depending on the sender (customer, co-designer or supplier) and the different states of the project development. Primary need for the co-designer is to keep always under control the current state of the information of interest, namely requirements, results, drawings and other documents. At a given moment it can occur that some parts of this information are under discussion with some partners, hence it is important for the codesigner having direct access to the position of counterparts to decide at best. The reasons causing a discussion with a partner are of two types: ü Internal, if during the progress of its own design activity (e.g. when working with the 3D model) the enterprise becomes aware of its inability to satisfy a requirement or it has to ask a requirement modification to a co-designer. ü External, if the upper level partner (or a certain lower level partner) asks for a requirement change to the enterprise. Generally, at a certain time there is some steady information that is agreed with the involved partners, and some other information under discussion that is waiting for a modification by the enterprise or an answer coming from a partner. It is very important that the two types of information are kept quite separate from each other. The reason is that the steady information is visible to all the interested partners, whereas the information under discussion cannot be spread in automatic way. This can only be communicated by the enterprise in the right manner and timely to the right partner. In fact, it may occur that a requirement modified by a co-designer is related to another of interest of the enterprise or of another co-designer. To decide which action must be undertaken is under the enterprise responsibility, for example: ü To make a counterproposal to the former codesigner to reduce the impact of the change. ü To review the relation binding the modified requirement with other requirements. ü To introduce changes to its own internal project to reduce the impact on the other requirements. ü To discuss with the latter co-designer, which has in charge parts influenced by the change made by the former co-designer, to verify its own opinion about the proposed change.

Versions: during the design process, it would be useful to consolidate time by time versions of the product documentation that correspond to relevant stages of the design project. Nowadays, versions are not systematically generated and, when created, they remain limited to CAD representations. Instead, the intuitive idea of version that the designers appreciate is a folder of documents of different kinds, ranging from technical characteristics to CAD drawings, from texts to images, representing at a given time all the knowledge describing the product under design. The folder should contain both public information, that is, information to exchange with co-designers, and private information, that is the original description or the reference to the source of the original information (e.g. 3D models). Details on already designed parts: a relevant problem, in particular for the enterprises with a complex product, is the risk of designing twice the same product. The risk increases when the design is not performed internally but assigned to co-designers. Presently the documentation maintained on externally designed parts is poor and not homogeneous, so it is very hard to compare the new part to design with those already designed in order to understand the potential reuse rate. Then, all the parts already designed should be described in a proper folder (typically, the last version obtained at the end of the corresponding design process). Such folder should contain at least a description of the part in terms of its relevant characteristics, to support the designer in comparing it with other similar parts and with the new requirements to fulfil. Past project structures: enterprises with complex products present also the need of maintaining an abstraction of similar projects, which could become a useful starting point for new projects. Such structures should be obtained as generalisation of analytical information on past projects. Requirements on this subject are not very specific, as the users are not used to have available an organised and wide amount of historical knowledge. Nevertheless, all of them emphasise the time wasted and the mistakes occurred when initialising a new project taking only advantage of the single designer’s experience.

2.4 Historical data

Before going to describe the realised Product Manager, an overview of the whole COWORK system is needed in order to have a more clear understanding of the scenario in which the COWORK Product Manager operates [7]. The COWORK system is made up by the following software modules, like pictured in Figure 6:

Since most of the new projects and decisions came out from previous experiences, it is important to define methods to maintain and support historical data; three kinds of historical data have been identified as a useful support for the design work.

3. The COWORK system

EDET: the External Data Exchange tool manages the data exchange with companies that do not have the COWORK Application. Thus this module provides a STEP phisycal file [9] containing product and process data, compliant to the AP214 schema [10].

4. The COWORK Product Manager Local SCM DB

Web server

SCM U s e r I n t e r f a c e

Internet IDET Internet DPM & SPM

EDET

SPM DPM DB

Nj CoWork

External Node AP214 compliant

The COWORK Product Manager is the module in charge of managing the knowledge that is strictly necessary to support the co-design activities of the single node within the network. Hence, it includes all and only those concepts pertaining to the description of the product whose design is in charge of the node. It does not intend to substitute the IT tools that the designers normally adopt for their design activities (e.g. CAD systems), but it is aimed at integrating these tools. In order to maintain a complete independence from any CAD system, a Visualiser&Markup tool [11] has been customised and integrated in the Product Manager allowing the user to share information with the help of “knowledge enriched drawings”. The product manager is mainly intended to support the project reuse and the negotiation activity by automatically keeping track of all the modification proposed or prepared to be sent. It is up to the user to decide when to send the data, thus allowing to work with hard boiled data. In addition it permits the simultaneous negotiation on different solutions for the same part, possibly corresponding to different candidates. On the base of the user need framework, described in the previous session, the module can be characterised by the following sentences:

Figure 6 The COWORK system architecture • SCM: it handles the local SMEs Competence Repository (Local SCM) as well as the search of information from the central Competence Repository (SCM), in order to support the identification of possible partners for a new project [8]. DPM & SPM : Product and Process Manager are the modules providing access to the local product model data, i.e. the Standardised Product Model (SPM), and to the local process model data (DPM) respectively, by encapsulating the relative databases. IDET : the Internal Data Exchange tool handles the communication between the node and other nodes of a COWORK network owning in their turn the COWORK application. The main contents of these communications are the product (technical) data and the process data

•

•

Since co-designers do not want their internal information, i.e. their knowledge, to be public, the only information that a company exchanges with another one is the minimal information needed to execute its own co-design activities; therefore the Product Manager must be able to represent the view of a co-designer as a complete and autonomous schema. The mean that has been identified as basic to describe a product to be co-designed is the following: a list of technical requirements (single values or ranges of values), with some additional information such as technical drawings and text documents. Therefore, the Product Manager must be able to manage those technical requirement values and states [12], as they are the views that the Main Contractor will have from the product that has been assigned to a co-designer. During the design process, the product data may change frequently until the definitive product is

•

reached. Therefore, Product Manager will have to be able to manage changes on technical requirements and the different product versions. Because of the emerged need of having a fixed format for the exchange of information related to the Product model: STEP has been selected (AP 214 in particular) as a way to have a neutral exchange format .

The Product Manager has four main functions: Composition that constitutes the concept of composition structure to decompose the whole design aim (root) in components, each of these to be assigned to lower lever co-designers Part-type that constitutes the concept of design of a given component: in other terms how a certain codesigner leads the design of the assigned component to be realised. Template that constitutes the concept of frame from which a composition structure can be created without defining the whole configuration by zero. A template is a useful functionality whenever composition structures with similarities exist, and then the definition of the same set of tree nodes and the same set of initial requirements for each node can be conveniently done by an automatic wizard. Family that constitutes the concept of container where to collect a set of part-type holding similar characteristics from the technical point of view. These characteristics are defined as family parameters.

Figure 7 The composition window. Both the root and leaves have associated a folder, named initial requirements, whose aim is to collect the technical requirements on the component itself. This folder maintains a set of product datum items that will be copied as specific requirements to be communicated to potential co-designers. The ability of Product Manager in managing the technical requirement values arises by the fact that each component represents a view of the whole design that a Main Contractor shares and keeps aligned with the co-designer in charge of designing the selected component.

4.2 The product composition A composition structure is the representation of the product to be designed by the single node, conveniently decomposed into a hierarchical structure of simpler parts to design; the main decomposition criterion is the identification of those components that are likely assigned to lower level co-designers (no matter if internal or external). In other terms, the hierarchy is not aimed at providing a sort of bill-ofmaterials, rather, it just puts in evidence the parts that are worth to be designed autonomously from each other. The intermediate nodes introduce the possibility to have a multi-level representation to highlight the fact that the features of a component are related to those of another one; the alternative nodes indicate that the definition of a given component is open and different directions can be undertaken in designing the final product [13]; finally the leaf are the components that can be assigned to external codesigners. Figure 7 shows a screenshot of the composition management for COWORK application.

4.3 Part-type, Family and Alias The SPM model introduces a separation between the concepts of component and part-type. While a component represents the technical task to be fulfilled by a co-designer, and therefore it collects all initial requirements as general guidelines for the component design, a part-type is the material object to be designed to realise the identified component. In other terms, a part-type is aimed at gathering all the knowledge about how a given co-designer designs a given component. This fact is very useful for codesign process purpose. The basic idea is that COWORK is able to follow all co-design phases, from the first contact with potential co-designers since results delivery. As usual practice, a SME contacts different potential partners able to design a given component before selecting the final one. During the negotiation phase as many parts as potential candidate co-designers are created and linked to the proper component to be designed. The application automatically copies the initial requirements defined on the component in each specific requirement folder for part-types.

Here in after, the node communicates and discusses the specific requirements separately with each single co-designers for which the part-type has been defined. Once a co-designers in charge of designing a given component has been selected, the other part-types are frozen and only the results for this part-type can be collected. The part-types that reach a conclusion in the design phase are stored as designed parts., i.e. a collection of results that can be re-used for new components: thus the same designed part may be linked to more than one component. The designed parts can also be classified into families according to proper organisation and distinction parameters, so as to provide a comfortable search tool for the identification of possible solutions for the components to realise. In addition aliases are allowed to denote the designed part in such a way to be recognised by the designer partners, which may follow a different naming schema for their internal products.

4.4 Template and versions Very often SMEs are asked to fulfil customisation of their products. This implies that a given intervention of design on these products is required. On the other hand, many parts of the composition structure for the new design are similar to old ones already defined, as well as many initial requirements for them. Thus, whenever a SME starts a new co-design activity, it can take advantage from having available the data set that can initialise the SPM data structure, thus avoiding manual re-entry by designers. A template is created by selecting an old data structure, and by choosing the composition nodes and product data that are worth being replicated. The use of template allows saving time and reducing possible oversights in defining new similar project structures. In addition the system provides the capability to consolidate time by time versions of the product documentation that corresponds to relevant stages of the design project: the version folder includes all the product documentation at that design stage, both public and private.

4.5 The Product Data As COWORK deals with co-design activity, product data mainly concern the information representing technical specification about the product itself. In particular, these are data prepared to be communicated to other partners. A product datum can be either a requirement that a given co-designer has to follow during the design, or a result collected from the same co-designer. Thus, technical requirements are the specification assigned by the Main Contractor to lower-level co-designers as constraints to their

work. On the contrary, technical results are generally communicated from co-designers to Main Contractor during and at the end of the collaboration. Three main types of product datum are supported by the Product Manager: Technical Quantity: a technical quantity is a parameter related to the main characteristics and functionality of the product, including the most important dimensions. Some parameters concern performances given by numbers, such as speed or weight, others concern aspects expressed by options within set of enumerated values. External Reference: an external reference allows to maintain a reference where to find additional information for the product. Typical examples are cabinets where technical manuals or quality manuals are stored, and WEB page addresses where webcatalogues are published. Document: A document is a physical file or a set of physical files. It can be either a set of Office files (e.g. text, Word, Excel, Power Point files) with specific meaning or a V&M document. A V&M document is a document managed by means of a Visualizer and Mark-up tool integrated within COWORK : it allows to handle geometrical information, in form of drawings and descriptive information by integrating further technical quantities. Moreover, creation and maintenance of links between the different types of information and the technical quantities is ensured. Summarising, through the V&M tool it is possible : ü To visualise the most common used raster graphic files, such as tiff, bmp, jpeg, pict and interchange vector files, such as iges, dxf and dwg and to make on them all the typical visualiser&mark-up operations. ü

To initialise a V&M document (including drawings, technical quantities and external document handling) through direct links between graphical and technical parts.

ü

User friendly interaction with SPM through drawings for setting and querying technical requirements and annotations.

ü

Complete handling of the negotiation process, from its beginning to its end.

The V&M tool is completely integrated in the COWORK application, avoiding so to the user the need to “switch” between different applications and to manually handle the exchange of information between them. It is completely in charge of the system to get information from the Product Model database and to visualise all the data retrieved, whenever possible, directly on the available drawings and, on the other end, to receive instructions from the user concerning modification proposals and the like and to convert and communicate them to the SPM. Under the operative point of view, each time a project is opened using the COWORK application, the user

has the possibility, through the V&M Document form, to access the V&M tool and to graphically manage all the related steps. A V&M document includes the following components: ü Basic drawing (graphic file): This element is mandatory. The shape description can be provided by using scanned handmade sketches thus originating raster format files, or it can be produced using company drawing/CAD tools, in which case the file can be either in vectorial format (e.g. dxf) or in raster format (e.g. bmp). ü

Link to Additional documents: these are optional elements, that can be produced using company drawing or CAD tools, representing details or other kind of graphic information. These drawings will be linked to the correspondent parts of the main drawing by means of COWORK tools. The relationship among the V&M document and the additional drawing files is managed both from the V&M tool and from the SPM database manager module. Additional document can also be Office documents (Word files, Excel spreadsheets, …) containing useful information, linked to the other parts as external references, again using COWORK tools.

ü

Links to technical quantities: textual entities in the basic drawing may be directly linked with Technical quantity in the Product Model database, to express those relevant drawing quotes subject to be discussed, in order to make then easier the negotiation. When the user changes some graphic entity, previously linked with a Technical Quantity, the value of the linked Technical Quantity is automatically changed too.

As additional support to the product data negotiation, facilities are provided to enable the user to navigate through the changes done by the co-designer to the V&M document, that is under discussion, and making so easier and faster to understand which are the proposed changes. Figure 8 shows two menus including some of the functions provided inside the V&M tool.

Figure 8 The V&M tools menu

5

The experimentation process

At present the experimentation of the effectiveness of COWORK application and methodology is in progress within SME clusters in Germany, Spain and Italy. With regard to the Product Manager, it has been planned that each single node defines for each project a composition structure where the root of a tree is the product to be designed and the leaf are the components that must be designed and assembled to realise the entire product. Then a part-type has to be defined for a component assigned to a given codesigner: in this way all the information regarding the part-type are grouped, managing two folders to collect the requirements on the design of the part and the incoming results for the part itself. A fundamental topic of the experimentation is the validation of the communication of the product data among co-design partners and the negotiation on them. Summarising, the results expected from the adoption of the Product Manager and the relative methodology are •

Use of the Product Manager to handle the data of the product, by subdividing these data for co-

designers in order to have proper views and to preserve know-how. •

To use an unique tool to correlate process and product data of a project

•

To be able to evaluate the supplied design results

•

To handle all the product data of projects in electronic format, faster retrieving/storage of data organised by design and sub-design in a hierarchical way, visualise drawings and mark-up them directly on files.

•

An easy and fast communication of the product data, thanks to the easiness of the adopted methods and tools ( similar to an e-mail)

•

An improvements of the negotiation process, since the system distinguishes automatically a proposal/counterproposal data from the current (accepted) data, making them available directly to the user.

The first results show that the COWORK methodology is introduced and applied without major problems and the results in terms of quality of the design cycle and of reduction of the design time are considerable. It is also expected at the end of the experimentation and validation process, to get the indication of required changes or the suggestion of some new features, deriving from the user experimentation One example can be the needs of having a sort of further levels of the classification of the product data: the possibility of searching/navigating through the requirement folders, having the possibility of filtering them by using filters as the proprietary of the requirement, or the class to whom the requirement belongs to ( shape , performances, …) may further reduce the time required by the co-design process.

6

Conclusions

In this paper a product model for supporting the negotiation phase in co-design activity has been described; the main characteristics provided by this model are: • • • •

representation of all the technical requirements related to the product to be co-designed management of the status of the technical requirements during the negotiation process possibility of taking advantage of past projects by means of the product family concept and project templates tracking of the product specification history for analysis purposes to aid project cost planning.

The Product Manager has been implemented by MS Visual Basic 6.0. The application runs on Window NT

and can work, as DBMS, with both MS Access and MS SQL Server accessed via ODBC connection. The Product Manager integrates a Visualiser and Mark-up application, that has been customised and integrated by means of MS VC++ and Imagenation C API tools.

References [1] W.J. Zhang, Q. Li 1999: Information modelling for made-to-order virtual enterprise manufacturing systems, Computer-aided Design journal, 31 (1999) 611-619 [2] A. Ohtaka, S. Sasao 1998: Development of new collaborative Design and Engineering Environment. In Globalization of Manufacturing in the digital communications era of the 21st century.. Edited By G. Jacucci, G.J. Olling, K. Preiss, M. Wozny 1998. [3] E. Westkamper 1998, Manufacturing in network-competitive Advanteges for Virtual Enterprises, Prolamat 98 Trento, Italy [4] ESPRIT Project 25360 COWORK http://www.tekniker.es/cowork [5] H. Afsarmanesh, A. Benabdelkader, L.O. Hertzberger, Cooperative information Management for distibuted Production Nodes, Prolamat 98 Trento, Italy [6] J.J.Zulaika, User requirements, ESPRIT Project 25360: COWORK deliverable D03 March 98 [7] J. Martin 1999: COWORK: IT Tools to Support Concurrent Project Development in networks of SMEs, ICE99,The Hague 14-15 March [8] M. Dobermann, S. Hassinger 1999, A Competence Repository for Small and Medium Enterprises, PDT Europe ’99, Stavanger, Norway [9]A.Klein, A. Schreiber 1999, Implementation of PDM/STEP processors for concurrent enginnering in a network of SMEs, Product Data Journal, June 99, edited by ProSTEP gmbh. [10] STEP IS-10303-Part 1,11,21,22,23,214, Industrial automation system and integration- Product Data Representation and Exchange, ISO. [11] Imagenation,, Spicer Coorporation, http://www.spicer.com [12] D. Biondi, F. Bonfatti, P.D. Monari, F.Giannini, M. Monti, 1999, A Product Model Supporting Co-design Activities: PDT ’99, Stavanger [13] F.Bonfatti, P.D.Monari, P. Paganelli 1994, Towards a rule based unified product modelling, DKSME 94,International conference, Hong Kong