Dr Thomas Paviot
email: thomas.paviot@supmeca.fr

Samir Lamouri
email: samir.lamouri@ensam.eu

Dr Vincent Cheutet
email: vincent.cheutet@supmeca.fr

Pr Samir Lamouri

A generic MultiCAD/MultiPDM interoperability framework

Keywords: Computer Aided Design, Product Data Management, Interoperability, Engineering Bill Of Material, EBOM, Service Oriented Architectures, SOA

Many Small and Medium Enterprises (SME) work as subcontractors (or co-contractors) for several clients for the design of mechanical components. During the design process, they must use a variety of Computer Aided Design (CAD) softwares and connect all the Product Data Management (PDM) systems of their customers. After defining the specific needs of these companies, we show that the available commercial CAD/PDM integrations, as well as the current literature, are inappropriate for a multiCAD/multiPDM collaborative design. Are first defined the few simple processes required to ensure an efficient collaboration. Then, the instantiation of these processes in our CAD/PDM integration can be split into four points: the general definition of a CAD product structure tree and its associated model, the conversion algorithm of the product structure to an Engineering Bill Of Material (EBOM), the creation of an Unified Modeling Language (UML) data model, an implementation based upon Component Object Model (COM) and Service Oriented Architectures (SOA) technologies. We conclude by presenting the results obtained from the demonstrator developed.

Introduction

In the current context of concurrence increase, design-time and time-to-market reduce, the concept of extended enterprise, where heterogeneous enterprises are linked at one moment and for one specific project, has become a standard for new product projects, especially for the automotive and aeronautical industries. In this case, subcontractors may become co-partners of the product development, with in particular the charge of designing a specific sub-part of the system.

To achieve such organisation, each operator of the project should access to right design information, at the right time, in a comprehensible format for him. It implies to ensure a consistent digital framework, where heterogeneous systems have to communicate. This implies the use of a coherent information system to ensure project/product data coherency [START_REF] Cui | Research on Integration Technology for Product Lifecycle Management System[END_REF]). Among all the possible authoring tools and data management systems that can be used in the extended enterprise field, we will focus in the proposed approach on the mechanical Computer Aided Design (CAD) tools and Product Data Management systems (PDM).

For major projects, the chain of subcontracting may include several levels. Small and Medium Enterprises (SME) involved in these projects, acting as subcontractors at level 3 or 4, are located at the crossroads of several extended enterprises (several of these major groups can be their customers). Designers have so to use many CAD systems and connect the PDM systems of their customers, as well as their own PDM. Commercial CAD/PDM integrations are often expensive, and require significant training before they can be used. However, SME do not have the technical skills and financial resources to deploy these solutions quickly and efficiently. The CAD/PDM integration is then a major issue for these companies, since the ability to integrate the extended enterprises information technology system tends to become an order qualifier.

On one hand, SME were identified as having the following needs [START_REF] Kadiri | Current situation of PLM systems in SME/SMI : Surveys results and analysis[END_REF]):

• a low-cost CAD/PDM integration, easy to use, deploy and maintain,

• an installation that would not cause any important modification of the current system, both on server and client side,

• an extensible integration, i.e. easily allow the interoperability with another CAD or PDM system.

On the other hand, the following specific needs were expressed by designers:

• export the product structure to the PDM in order to manage an EBOM and CAD documents dependencies,

• allow an asynchronous collaborative design on a part of the mock up, enable data exchange with customers or suppliers,

• enable a project review based on 3D visualization.

As a consequence, two main issues appear crucial for SME: reduction of design time and risks of mistakes in the product structure management thus enabling them to compete for a call to tender.

To achieve these two issues, we propose a multiCAD/multiPDM integration framework, based on two main concepts : first a mediation architecture between the different involved systems, allowing a great agility in terms of system connection, and second, data exchanges between these systems based on standards format, like Standard for the Exchange of Product model data (STEP).

The article is structured as follow. Section 2 overviews different approaches existing in the literature on the CAD/PDM interoperability issue. Section 3 demonstrates the validity of our approach according to a graph-based model of dependencies in the Digital Mock-Up (DMU) description, and presents the conversion rules of our MultiCAD/MultiPDM integration framework to export the product structure to an Engineering Bill Of Materials (EBOM). Section 4 describes the implementation architecture and the results obtained on different use cases. Finally, section 5 presents the conclusions and open new perspectives.

CAD/PDM interoperability issue

The problem of CAD/PDM integration can be seen as a problem of system interoperability as seen before. Among the exhaustive list of possible definitions for interoperability that has been listed by Baina (2006), we used the proposition of [START_REF] Eif | European Interoperability Framework -White Paper[END_REF] for whom interoperability can be reached at different levels:

• Technical layer (exchanged data et messages) : to exchange information, we should first have a transport vector available between the two systems that communicate, i.e. a functional data vector,

• Semantic layer (information and services sharing): a functional data vector is not enough, if the exchanged data cannot be understood by the two systems. Data, with attached meaning, become so information that can be treated by the two systems,

• Organisational layer (interactions between business unit/process/people through the organisation): an adapted organisation should be thought to ensure the information exchange.

These layers have to been simultaneously faced to guarantee a complete interoperability between information systems. In this article, we will only tackle the first two layers (i.e. technical and semantic) in a first time, the organisation layer implying problems relative to processes and their modelling that we will not present here.

Technical interoperability

In this section we will study and compare the possible architecture allowing to realise the technical interoperability between several CAD and PDM systems. To guarantee the information exchange between systems, each couple (i; j) of systems should be interoperable, i.e. at least one path linking each couple of node (i; j) should exist in the chosen network topology. Among all the possible network topologies, two types of architectures arise from the study of the PLM interoperability literature [START_REF] Guyot | Product data and digital mock-up exchange based on PLM[END_REF]):

• A point-to-point architecture, whose topology is a complete graph, in which each system i is connected to the system j through a specific interface;

• A mediator architecture ("star" topology) in which a new system is added in the middle. In this architecture, first introduced by Wiederhold (1992), the added system is called information mediator.

If we compare the two architectures either in terms of Total Cost of Ownership (TCO), or in terms of system agility, the mediator architecture is the most-suited for the system interoperability issue, especially in the context of SME integration in the extended enterprise.

Since the article of [START_REF] Wiederhold | Mediation in the architecture of future information systems[END_REF], SOA (Service Oriented Architecture) [START_REF] Gottschalk | Web services architecture overview[END_REF]) and Web Services [START_REF] Booth | Web Services Architecture[END_REF]) have allowed the development of the concept of service-oriented mediator. First presented by Benaben et al. (2008), this service-oriented architecture has been demonstrated as the most-relevant one for information systems interoperability in a larger context by [START_REF] Paviot | Design and logistics IT federation through Product Lifecycle Support standard[END_REF].

Semantic interoperability

The standard ISO-14258-1998ISO-14258- (1998)), relative to the enterprise modelling, precise that the semantic interoperability between two (or more) information systems of enterprise can be tackled in three different ways:

• Integration: a common standard of data model is used for all the system components. The integration process implies so to merge the data models;

• Unification: a meta-model common to all system components furnishes a way to establish semantic associations;

• Federation: distinct models are dynamically associated. This approach is usually using semi-automatic tools, based on heuristic methods that mainly compare the terminology and the data structure to detect couples of concepts that are linked at the semantic level (similarity or equivalence) and called mapping.

According to the discussion of Hoffmann ( 2008) on these three different approaches, the unification approach has been chosen in our proposition. In such case, the study of the literature on the PLM interoperability enlightens two different strategies: authors can either define an ad hoc data model or use and implement a standard data model.

A priori the solution of a neutral format translation appears to be adapted [START_REF] Fenves | Product Information Exchange : Practices and Standards[END_REF]). Among the different existing standards existing in the PLM field, STEP file format is an internationalized standard [START_REF] Pratt | ISO 10303: the STEP standard for product data exchange, and its capabilities[END_REF]) that offers various means of storing, exchanging and archiving the product data in a longterm approach. Several authors so used this standard to implement a CAD/PDM interoperability. Oh et al. (2008) develop a CAD/PDM integration based upon EXPRESS mapping language and an UML mapping diagram. Methodology of [START_REF] Zhang | An Internet based STEP data exchange framework for virtual enterprises[END_REF] maps IGES, STEP AP203 and STEP AP209 standard. However, although the STEP Schema has been specified for exchanging data usually stored by PDM systems [START_REF] Machner | Mapping the user requirements from the VDAORG with the STEP PDM Schema[END_REF]), the use of STEP file format to extract the DMU information leads to two problems: CAD editors partially implement the ISO standard (Oh et al. (2008)) and STEP processor acts like a filter on native data that is problematic in the case of an homogeneous CAD/PDM integration, i.e. both designers working with the same CAD tool. [START_REF] Song | Beyond geometric CAD system : implementation of STEP translator for multiple-views product modeller[END_REF] specifies a CAx/PDM integration platform based on product model defined by STEP AP203. The results of such works have been implemented on the basis of Cooperative Design Modeller (CoDeMo) core.

In order to validate the two aspects of the interoperability framework we propose, we study in the next section a graph description of both CAD and PDM data models, to enlighten the similarities and the differences between the two models.

Proposed approach

The concept of item can be considered as the key-item of the enterprise since it is used by every department: design, maintenance, manufacture, distribution, inventory management and Material Requirement Planning (MRP). Each of them view the BOM 'as maintained', 'as built', 'as designed' etc. Parts are necessary to manage the engineering changes requests as well as the product configuration [START_REF] Estublier | Reconciling Software Configuration Management and Product Data Management[END_REF]). In order to allow the connection to the Information Technology (IT) system of the extended enterprise, we consider that our CAD/PDM integration should focus on EBOM checking, reading and updates.

On the contrary of the manufacturing field where the notion of Manufacturing Bill Of Material (MBOM) is perfectly defined and shared since the definition of [START_REF] Orlicky | Material requirements planning: the new way of life in production and inventory management[END_REF], there is not a univocal definition or proposition of product structuring in the design process: each entity (people or organizations) has to specify a methodology (or a set of best practices) in order to organize the product according to an explicit and shared semantics covering the whole extended enterprise [START_REF] Tomovic | Measuring the Impact of Product Lifecycle Management: Process Plan, Waste Reduction and Innovations Conceptual Frameworks, and Logic Model for Developing Metrics[END_REF]). In our approach, we consider that the possible CAD/PDM integration exist in a specific extended enterprise, and so the product breakdown process and its attached semantics is shared between all the actors of the product development process, even if they do not belong to the same organization.

We then have two different structures describing the product: a CAD document structure, which defines the links between CAD files, and an EBOM that describes the structural links between PDM parts. This section presents the methodology used to convert a CAD product structure and all the dependencies to this double structure in the PDM system.

Dependencies in a DMU

Although each CAD software implements its own data model and graphical user interface, we noticed that the ones we studied share a set of common basic features, as well as the same way to store data on the hard disk. In particular, we noticed that a DMU is completely defined by:

• a set of CAD files that describe the geometry of the system. Each software uses a proprietary file format to store geometric data, but the information is structured by two kinds of files: parts and assemblies (CATPart and CATProduct for CATIA V5 T M , SLDPRT and SLDASM for SolidWorks T M , IPT and IAM for Inventor T M , PRT and ASM for Pro/E T M ),

• a set of files that define the different configurations of a part. These are usually text CSV formatted files that can come from a spreadsheet application,

• a set of components linked with parent/child relations. Components can be instances of CAD files.

These dependencies are presented for a simple example: fig. 1.a presents the 3D view of a pneumatic grip, that is defined in Autodesk Inventor These data must be stored into the PDM to ensure their coherence during the design process.

As a consequence, we define an directed graph-model of these dependencies that leads to the data model to be implemented (fig. 2).

Three different types of elements (i.e. the v ¯ertices of the proposed graph model) have been defined:

• F is the set of all the necessary and sufficient files needed to completely describe the geometry of the digital mock-up. Each of these files describes a part of the system.

• I is the set of components that appear in the design tree view that is generally displayed on the left part of the CAD software window. These components can be, or not, an instance of an element of F .

• C is the set of files that define different configurations for a part or an assembly.

Each file f ∈ F can be instantiated more than once, i.e. the same CAD file can be instantiated several times in the assembly. In the example of fig. 1, the assembly is composed by 2 fingers (present in the tree view), but only one finger file exists. The current trend to standardize products leads to a reduction in the elements of F to describe the geometry of a product. We can then write the following cardinality property:

0 ≤ card(C) ≤ card(F ) ≤ card(I) (1)
Four different types of directed links (i.e. the a ¯rcs of the proposed graph model) between these elements can be identified:

• structural links (S L ) between elements of I,

• geometrical description links (G L ) between an element of I and element of F ,

• configuration links (C L ) between elements of F and elements of C,

• structural saved links (S L ) between elements of F . They can come from a S L structural saved link or parametric link between two parts ("in-context" design, parameters relationship).

0 ≤ card(S ) ≤ card(S) (2)
The set of geometrical description links (G L ) can be seen as a surjective function from I to F , which is in adequation with the cardinality property between the two sets.

Let D be the set including all DMU data (D = C ∪ F ∪ I) and L the family of dependencies between these data (L = S L ∪ G L ∪ C L ∪ S L ). The graph DM U (D, L) contains the required information that has to be stored in the PDM database. We define the subgraph P S(I, S L ) as the digital product structure.

Since we defined the graph DM U (D, L) as the model of the necessary dependencies to keep the CAD data coherent, once the current work of the designer is saved to his local hard disk, DMU is a connected and directed graph. An element of I cannot handle a self-reference so there cannot be any loop in P S(I, SL)

(3). if ∃(I i , I j ) ∈ S L ⇒ (I j , I i ) / ∈ S L (3)

as-designed EBOM graph model

Similarly to the MBOM [START_REF] Orlicky | Material requirements planning: the new way of life in production and inventory management[END_REF]), we can define an EBOM as a graph E(P, L), the vertices P being parts and the arcs L structural links (cf. fig. 3). E is a directed, weighted 1-graph. Weight w i of arc L i is given by the number of elements of its parent. The EBOM can be exploded into n 1-level EBOM in order to simplify the treatment.

Product Structure to EBOM conversion rule

The two structures defined in the previous sections, and especially P S(I, S L ) and E(P, L), are quite similar in terms of graph property. Nevertheless, the semantics between them may differs and we then have to determine which CAD components have to be converted to PDM parts and the conversion rules that need implementing. The conversion rules must solve these two issues:

• the rule for converting CAD instances into parts

• the rule of constructing EBOM links from the product structure, i.e. define an application from P S(I, S L ) to E(P, L).

The first approach we investigated is the one that is usually implemented in the CAD softwares: each new CAD component, i.e. a vertex of the P S(I, S L ) graph, corresponds to a PDM part, i.e. a vertex of the E(P, L) graph. But, by using this rule, three issues have to be faced.

The first issue correspond to the core difference between the arcs of the E(P, L) graph, that are weighted, and the ones of the P S(I, S L ) graph, that are not. For instance, in the example of the grip (fig. 1), two fingers exist in the digital product structure, whereas the EBOM is composed by one item "finger" linked to the item "grip" by an arc with a weight equal to 2. In this case, we have to check first the DM U (D, L) graph: the two vertices "finger" present in I are linked to the same vertex "finger.ipt" in F , i.e. the two instances of the digital product structure are attached to the same geometry and so can be grouped together in the EBOM. To obtain such result, we use the following algorithm: ∀I i ∈ I, a recursive parsing is performed to get all the child components I k,l,m... . For each of these (I i I k,l,m... ) found links, the corresponding EBOM parts are queried then the link (P P ) is created with w = 1 otherwise w is incremented if the link is already created. The algorithm is initialized with the root node I 0 and recursion ends when I i does not have any child.

The second issue concerns the instances referring to a part with no mass: in an early design stage, each part may be modeled by few geometric characteristics (point, line, plane, etc.) on which future mass will stand. Another usual design methodology uses master sketches that drive the geometry of the DMU, since they allow a robust and flexible design. These master sketches must not be converted to an EBOM part: they have to be considered as tools in the DMU building process. We decide to put an MS tag (for Master Sketch) in the name of the instance, to specify to the translator that it should be skipped. These considerations lead to the following single rule: all instances that are not "MS" tagged are converted into parts.

The third issue appears when the designer uses a standard component or a purchased component. As we can see in fig. 4 These three issues can be considered as operation of type vertices clustering on the graphs, and so do not change the graph structure. As a consequence, the transformation from P S(I, S L ) to E(P, L) is a surjective application, which validates our approach.

Implementation

This section explains the implementation of the previous algorithm: subsection 4.1 focuses on the data model whereas 4.2 presents the functional architecture of the implementation.

4.1 Data model [START_REF] Eynard | PDM system implementation based on UML[END_REF] define a complete UML class diagram of a product structure. However two problems subside: on one hand, the dependencies between the CAD files are not described; on the other hand this model is strongly linked to the PDM system they study and is not easily portable to another system. We propose the below model (fig. 5) that uses elementary classes available on any PDM system (Part, CAD Document, Generic Document) and for which implementation does not require any customization on the PDM server side. The double Part and CAD document structures appear on this diagram. The "Structure links" connect the "Part Master" class with the "Part" class that can be iterated during the design process. Each part is described by 3 "Generic Documents" that embed the 3D Preview, exchange files and configuration table files. Each "Part" is described by 0 or 1 "CAD Document" which refers to a native CAD file.

Implementation architecture

The implementation architecture relies on two technologies (cf. fig. 6):

• Component Oriented Model (COM): this Microsoft T M Windows T M specific technology is designed to allow the automation of manual processes. The data model of each CAD software is specific, but we implemented a COM client that relies on a set of generic basic classes/methods that are available in each software. A simple XML mapping file is used to instantiate our generic client object. COM client parses product structure, export files as STEP or 3DXML.

• Web Services (Service Oriented Architecture -SOA): a service is an implementation independent interface with an explicit definition; a service is loosely coupled, location-transparent and called by interoperable communication protocol; a service encapsulates re-usable business functions.

During the last years, PDM editors have made significant efforts to provide standardized SOA [START_REF] Lee | An implementation methodology of SOA based PLM system[END_REF]) that make their system interoperable. Simple Object Application Protocol (SOAP) (WWW Consortium ( 2007)) requests deal with part/documents/links creation on the PDM. For the CAD softwares that do not provide any COM server, or that run on other operating systems, we developed a simple STEP parser that can extract the product structure information (Oh et al. (2008)).

3D Visualization

To achieve the 3D visualization of our integration, a number of file formats are available that can satisfy the needs of all users by allowing 3D data, and sometimes other data such as 2D drawings and documents, to be viewed from a fairly simple and free of charge viewing tool. These include formats such as UGS'JT, Dassault Systèmes'3DXML, 3D Industry Forum's (3DIF) U3D, Tech Soft's HOOPS Stream, and Web 3D Consortium's VRML and X3D. 3D visualization files are created from the CAD session with the appropriate COM method, exported to the PDM and converted into 3D preview "Generic Document" (cf. fig. 5). These documents can be accessed by any authorized user even if the CAD software is not installed on his computer. It is especially useful for PDM systems accessible from a lightweight client: a collaborative project review can be done from almost any computer, as long as the appropriate viewer is installed and configured.

Results

We developed a demonstrator that implements previous work. We identified four elementary processes that we implemented to achieve a simple CAD centric collaborative design:

• export of the CAD data to the PDM,

• download of the CAD data from the PDM,

• request a lockup of a part (checkout) and begin a new design process,

• upload modifications to the PDM (check-in) and allow other designers to access new part iteration.

The product structure of the example of fig. 1 from Autodesk Inventor T M was exported to PTC Windchill T M PDM. We also investigated further with bigger and more complex DMUs (cf table.1). Table 1 Results of CAD export to a remote on-demand PLM platform

Conclusion and further works

In this paper, we presented a methodology to convert a CAD product structure to an EBOM, independently of the softwares used. We defined an UML data model that was implemented to provide an easy to use/deploy/maintain and low-cost bidirectional CAD/PDM bridge. Basic features of collaborative design work are fully functional but we still encounter problems to properly handle events sent by the CAD or the PDM when a modification occurs on either CAD or PDM sides. Further short term work will focus on issues of change management in product structure and synchronization of data. An other issue is to develop a methodology to convert an Engineering Bill Of Material into a Manufacturing Bill Of Material (MBOM), so that our demonstrator can connect to an Enterprise Resource Planning (ERP) system (CIMdata ( 2006)) and cover a larger scope of extended enterprise needs [START_REF] Paviot | Design and logistics IT federation through Product Lifecycle Support standard[END_REF]).

Figure 1

 1 Figure 1 Dependencies for a simple DMU (screenshots from Autodesk Inventor T M )

Figure 2

 2 Figure 2 Graph model for the instances/files dependencies

Figure 3

 3 Figure 3 EBOM graph model

  , he uses the 3D model of the component obtained from the supplier database (cf. fig.4.a). This model is generally available in the STEP format, and once it is instantiated in the CAD session, many components are created (cf. fig.4.b). In this case, it is not necessary to create the PDM parts corresponding to each item, but only the one corresponding to the root node of the structural tree (cf. fig.4.c). This is achieved by adding a PURCHASED tag to the instance name.

Figure 4

 4 Figure 4 Product structure conversion for standard components

Figure 5

 5 Figure 5 UML data model of the converter

Figure 6

 6 Figure 6 Architecture implementation based on COM and SOAP technologies


Chiara E Catalano
email: chiara.catalano@ge.imati.cnr.it

Elena Camossi
email: elena.camossi@ucd.ie

Rosalinda Ferrandes
email: rosalinda.ferrandes@g-scop.inpg.fr

Vincent Cheutet
email: vincent.cheutet@supmeca.fr

Neyir Sevilmis
email: neyir.sevilmis@igd.fhg.de

A Product Design Ontology for Enhancing Shape Processing in Design Workflows

Keywords: Ontology-driven retrieval, Product Design workflow, Digital shapes, Shape processing tools 1

Effective and efficient information management and knowledge sharing has become an essential part of more and more professional tasks in the Product Development Process. Among the varius Knowledge Management technologies, ontologies offer new possibilities for representing, handling and retrieving product related knowledge, and for online collaboration. We conceived a Product Design Ontology (PDO) which especially addresses researchers in industrial product design and engineering analysis who need to share shape data and to develop software tools. In particular, we formalised the task-specific information associated to a shape, and the functionality and usage of shape processing methods in specific tasks of the design workflow. The PDO, thanks to the ontologydriven metadata on shapes and tools, may be also useful in industry on the one hand for training and for retrieving shape-related information, on the other hand for supporting benchmarking of processing tools and gathering the knowledge about shape processing workflows.

Introduction

Due to worldwide competition and to recent technological improvements, product time-to-market has been reduced in the last years and specialisation of competencies in the Product Development Process (PDP) has been growing. PDP is a very complex process which requires a variety of expertise according to the peculiar activity considered. Thus, the number of different actors involved in PDP increases, as well as the multiplicity of their specific knowledge areas.

In some cases, companies are becoming Virtual Entreprises [START_REF] Katzy | The Virtual Enterprise. Handbook of Life Cycle Engineering: Concepts, Methods and Tools[END_REF], i.e. (possibly temporary) networks of independent companies which share their means, competences and resources in order to carry out joint projects which can exceed the capacities of each single unit. Indeed, Virtual Entreprises are generally multi-site, multi-lingual, multi-cultural, multi-function and multicompetence. In car industry, for instance, even traditional companies are moving the range of their main knowledge and competency areas from the complete product design and manufacturing to the design and the assembly of the product only. As an example, the number of car suppliers is increasing, as well as their specific competencies: often, suppliers do not only manufacture a part according to the main company's design, but they also participate in the part specification process.

Due to such a change of mentality in the design activity, to perform an efficient job, companies and actors of PDP need to access the right information in a usable format at the right time. Throughout the PDP, a large number of information suitable for each specific application is available. This information needs to be efficiently and effectively represented and retrieved; thus, a strong interaction among the actors is required to share product data.

Among the proposed information technologies, Electronic Data Interchange (EDI) has been introduced to exchange transaction details electronically between customers and suppliers, such as purchase orders or part specifications [START_REF] Mukhopadhyay | Business Value of Information Technology: A Study of Electronic Data Interchange[END_REF]. Alternatively, Knowledge Management (KM) consists of a range of practices used by organisations to identify, create, represent, and distribute knowledge for reuse, awareness and learning [START_REF] Nonaka | The Knowledge-Creating Company[END_REF].

Beyond the mere support for collaboration and share, the need for easy, quick and secure access to data during the product design process led to the development of Product Data Management (PDM) systems [START_REF] Lee | Principles of CAD/CAM/CAE systems[END_REF]. PDM systems are widely adopted in industry: they combine the scope of technical and engineering data, and support managers in the organisation of the increasing amount of information required by product design, manufacturing, and maintainance. Rooted in CAD (Computer Aided Design) and PDM systems, Product Lifecycle Management (PLM) aims at connecting various product stakeholders over the whole product lifecycle [START_REF] Amann | Product lifecycle management: empowering the future of business[END_REF] [START_REF] Antti | Product Lifecycle Management[END_REF]) [START_REF] Stark | Product Lifecycle Management (PLM) -Report on State of the Art, John Stark Associate[END_REF]) and aims at enabling them to handle company projects.

Unfortunately, commercial PDM and PLM systems are not able to support efficiently the design phase, which is dynamic, as well as the information generated and used in the PDP. Especially in digital mock-up, a specific digital product representation fits each phase. Moreover, specific shape information is relevant for each actor [START_REF] Gero | Modelling multiple views of design objects in a collaborative CAD environment[END_REF], and specific interface workflows between two different actors are needed in order to transform the product from one description to another, taking into account both the geometry and the usage context [START_REF] Hamri | Interfacing product views through a mixed shape representation. Part 1: Data structures and operators[END_REF]. Commercial PDM and PLM systems are not effective in assisting such a crucial phase, because they are mainly document-oriented and provide a general description of the product with no special customised view. Furthermore, PDM/PLM systems, which rely on Database Management Systems, opportunely structure the information, but fail in encoding the relationships among the engineering data and their evolution in the PDP.

To overcome this lack, we herein present an ontology for product design, the Product Design Ontology (PDO). The PDO is centred around shape processing, and its aim is to assist a PDP actor who needs information related to the shapes and tools intervening in the PDP different tasks; in this respect, we formalised the interpretation of the information associated to a shape and the functionalities and usage of shape processing methods.

The PDO was originated in the framework of the Network of Excellence AIM@SHAPE (AIM@SHAPE), whose intent was the integration of research on digital shapes modelling and processing with knowledge technologies and semantic web tools. Among the objectives of the project, there were the definition of a common framework for formalising, processing and sharing shape knowledge, and the set up of a shape-related knowledge base, the Digital Shape Workbench (DSW) to be coupled with efficient communication and collaborative working infrastructures. The DSW permits to store, integrate, adapt, enhance and retrieve shapes and shape processing tools, together with relevant scientific publications. In particular, two Common Ontologies (COs) -one for shapes and the other one for shape processing tools -were proposed: they allow for respectively a generic (i.e., nondomain related) specification of shape representations and shape processing tools. The COs have been integrated and complemented according to a bottom-up approach, relying on the development of three ontologies, which address the need of particular shape application domains (i.e., Product Design,Virtual Humans, and Shape Acquisition and Processing) [START_REF] Vasilakis | A Semantic-based Search Engine for 3D Shapes: Design and early Prototype Implementation[END_REF].

Product Design has been selected as one of the shape processing sub-domains of interest because PDP is one of the application contexts where semantic web techniques and ontologies are promising for retrieval and online collaboration support. In particular, ontologies, which formalise a common understanding on symbols and terms used, enable us to share a common vocabulary, thus to support communication and transfer of knowledge among different product stakeholders [START_REF] Giménez | PRoduct ONTOlogy: Defining product-related concepts for logistics planning activities[END_REF]. Indeed, the scientific literature reports on several proposals where ontologies are applied for the formalisation of CAD/PDM/PLM knowledge [START_REF] Horvàth | Development and Application of Design Concept Ontologies for Contextual Conceptualization[END_REF] (Jun et al., 2005) [START_REF] Kitamura | Ontology-based systematization of functional knowledge[END_REF] [START_REF] Kopena | Functional Modelling of Engineering Design[END_REF] [START_REF] Li | Semantics-Based Design Knowledge Annotation and Retrieval[END_REF] [START_REF] Patil | Ontology-Based Exchange of Product Data Semantics[END_REF] [START_REF] Posada | Using Ontologies and STEP Standards for the Semantic Simplification of CAD Models in Different Engineering Domains[END_REF].

In particular, [START_REF] Horvàth | Development and Application of Design Concept Ontologies for Contextual Conceptualization[END_REF] presented an ontology-based approach towards the definition of design features, while [START_REF] Kitamura | Ontology-based systematization of functional knowledge[END_REF] and [START_REF] Kopena | Functional Modelling of Engineering Design[END_REF] investigated the modelling of functional knowledge for Product Design. In [START_REF] Li | Semantics-Based Design Knowledge Annotation and Retrieval[END_REF], the authors propose the application of a knowledge-based formalisation of conceptual design know-how and intentions to improve the design retrieval and reuse. In [START_REF] Posada | Using Ontologies and STEP Standards for the Semantic Simplification of CAD Models in Different Engineering Domains[END_REF], the authors use an ontology to support the semantics-driven simplification of CAD models applied to the visualisation and the design review of large plant models. In [START_REF] Giménez | PRoduct ONTOlogy: Defining product-related concepts for logistics planning activities[END_REF], the authors propose a product ontology to share information on complex product models, defined according to different levels of detail, related to both the structure (with respect to a bill of material decomposition) and the abstraction (i.e., Family, Variant Set, Product). Another work addressing the exchange and reuse of product models knowledge is [START_REF] Gupta | A Feature-Based Framework for Semantic Interoperability of Product Models[END_REF], where the Domain Independent Form Features (DIFF) Model, describing the operational semantics of features, is used to define an ontology of form features.

Since the last ten years the National Institute of Standards and Technologies (NIST), has worked on a Core Product Model (CPM) [START_REF] Fenves | CPM2: A Core Model for Product Data[END_REF] to support intelligent design repositories for sharing and reusing the knowledge on design artifacts, focussing on the aspects of form, function and behaviour. More recently, the University of Missouri-Rolla (UMR) followed the same approach to enhance their design repository (Bohm et al. in press). Our work is complementary with respect to the CPM because we give a geometric description of shape models, and we investigate the aspects of behaviour according to particular subprocess of the PDP. The traditional functional knowledge, as addressed by [START_REF] Fenves | CPM2: A Core Model for Product Data[END_REF], may be easily integrated in the PDO to complement the product description.

However, the interest of the research community in the integration of product semantics using knowledge technologies does not usually focus on the annotation and retrieval of shape data as addressed in this paper. Moreover, even if the general approach we adopted is applicable to the whole PDP, we especially investigated the requirements of freeform modelling and engineering simulation, proposing a very detailed representation of the knowledge entailed by the related design workflows, and ad hoc solutions for their enhancement. In particular, the PDO addresses two general scenarios: 1) the user, asking queries either to the DSW or to any repository, retrieves application-driven information about shape processing methods and tools according to his/her point of view on the product; besides, he/she may access to suitable test shapes for benchmarking his/her shape processing tools;

2) the user may ask for a pipeline of tools with a specific functionality; besides, a software developer may benchmark his/her own tool searching for tools that perform the same tasks.

The benefits of the use of ontologies for these scenarios are twofold. On the one hand, they are able to make the communication among researchers working in different areas or addressing different aspects of PDP straightforward; in addition, the development of further software is simplified because developers may refer to the well-formalised Web Ontology Language (OWL) syntax we used for defining the PDO. On the other hand, since the formalisation we propose was designed in collaboration with experts in the field, the proposed terminology and processes are trustworthy.

Although this work was conceived in a research context, its scope may be extended to industrial applications. In fact, the PDO, queried according to the former scenarios, recalls PDM capabilities which are strictly focussed on the digital process of a product. Furthermore, it can assist the training of unexperienced engineers or new partners of a company, who need to learn commonly used design workflows in the PDP, as well as the particular procedures adopted in a company.

Finally, we point out that the work presented in this paper does not contrast with initiatives for the development of workflow languages, e.g., (YAWL) (XFlow), workflow patterns (Workflow Pattern), and workflow ontologies as that proposed in (OWL-WS). The methodologies and the software solutions they provide can be applied to handle the general aspects and the execution of PDP tasks.

Therefore, they could be applied to complement this work. By contrast, the PDO supports and enhances the specific domain requirements of researchers dealing with design workflows. These workflows are executed by developing the two investigated PDP tasks.

The paper is organised as follows. In Section 2, a description of the subset of the PDP we selected as application context is provided and three usage scenarios are detailed. In Section 3, we describe the development of the PDO by detailing the main concepts and relationships related to the representation and the exploitation of workflows within the Product Development Process. In Section 4 a significant validation scenario for the PDO is discussed, while Section 5 concludes the paper with some final remarks.

Product design user scenarios

The Product Design Process formalised in the PDO is consistent with the Application Activity Model (AAM) of AP214 of the ISO Standard 10303, STEP -Standard for the Exchange of Product Information (STEP); therefore it provides an agreed model of the Product Design workflow (see Fig. 1). The essential characteristics of a new product to be put on the market are expressed in terms of functions, size, materials, weight, etc (T1_Product_Definition). Starting from them, designers work on the creation of the object shape (T2_Product Styling). When the final shape has been defined, a first three dimensional (3D) digital model is built. Then, it is translated into a more detailed and precise one, which is useful for the engineering phase of the PDP (all these stages are included in T3_Product_Design). In particular, the evaluation of the product from the engineering point of view is performed transforming the model in a representation suitable to the execution of an engineering analysis (i.e., Finite Element mesh). It often happens that modifications on the original model are required because of unsatisfactory results (T3_4_Calculation and Analysis). By contrast, two scenarios of engineering analysis are considered: the first addresses the preparation of a design model to perform a behaviour simulation through a Finite Element Analysis (FEA), including the process of shape simplification; the second deals with the simulation post-processing, where simulation results are examined and interpreted.

Finally, the formalisation of grouping mechanisms is discussed apart. From the analysis of these scenarios, we derived meaningful Competency Questions (CQs), which guided the design of the PDO.

Freeform modelling

Based on the product definition, the first step of the product design is the creation of a new object taking into account functional and aesthetic characteristics. Stylists translate such constraints into some alternatives shapes, which can be very complex from the geometric point of view thanks to the advanced manufacturing technologies. This requires the employment of freeform modelling techniques, typically working on the parametric NURBS representation for curves and surfaces to be compatible with down-stream applications. The scenario we consider mainly addresses developers of freeform deformation tools who have to test their own tool with several suitable models and to compare it with the capabilities and results of other existing tools. In this case, the connection with the DSW is very strict: in this repository, in fact, it is possible to search for NURBS models enriched with significant geometric metadata, and software tools with specific functionalities. Similarly, the same scenario can be envisaged in an industrial context, where a CAD user searches for past projects in the company repository, while the formalisation of the early design workflow can be used for training purposes.

In Fig. 2, the typical steps of the freeform deformation scenario are shown. After searching for suitable models (Fig. 2(a)), possibly belonging to some specific industrial category, the first action is verifying if the properties of the model fit the input requirements of the modelling tool to be tested (Fig. 2(b)); in case they did not, the model has to be corrected (Fig. 2(c)). Then, the software can be run (Fig. 2(d)) and the results evaluated (Fig. 2(e)).

For instance, a good connectivity between patches is commonly required in CAS/CAD applications.

The deformation tool under test would reasonably require a smooth surface in input and should provide a smooth surface in output. The input model selected in the repository has to fulfil such a property. Specific evaluation tools -which can be retrieved also in the DSW-permit to check the regularity of the shape, detecting the areas where geometric constraints fail and have to be reestablished; they can be used before and after the deformation process.

Examples of CQs associated to this scenario are: search for a design model represented as a BRep with NURBS patches and belonging to the automotive category; search for tools that check the connectivity between patches of the design model. Quality check of digital models is a crucial task when transferring from one system to another: due to the different tolerances used, a CAD model can be invalidated and then become useless in the downstream processes. As a consequence, quality checks occurring more frequently in some type of models transfer have been identified and included in this scenario. We consider in particular: checks for avoiding non-manifold models (within specified tolerances), which are important for all the transfers (e.g., check for duplication of elements; check for self-intersections and singularities); checks for preventing configurations that make downstream applications difficult, especially for geometric computation (e.g., tests for mini-elements; tests for edges lops and for the orientation of the surface normal).

In this context, examples of CQs that can be successfully answered are: find software tools that support the specific quality check of self-intersection; find the types of geometric conditions that are necessary for a FEA; find the types of checks to consider when performing the meshing task.

Finally, the CAD models we refer to in our PDO may reasonably contain not only geometry, but also some well-defined form features, whose number and type is a further indication of the complexity of the shapes. In fact, traditional 3D shape representations are generally able to support only geometric information; thus, features were introduced in product design as a modelling approach aiming at bringing a specific kind of semantics in geometry [START_REF] Shah | Parametric and feature-based CAD/CAM[END_REF]. They carry a different semantics according to the area of process under observation; in particular, form features are strictly connected to the shape of the object. The benefits of feature-based modelling have been well

recognised and CAD systems largely adopt it both in the mechanical and freeform domains.

Engineering Analysis

During the PDP, the simulation stage evaluates the physical behaviour of any engineering component constituting the whole product, which is subject to various kinds of loads and conditions.

Finite Element (FE) approaches are widespread in industry to analyse the mechanical behaviour of a component. They apply mechanical models of behaviour on a appropriate model, i.e., a FE mesh. A FE mesh represents the discretisation of a continuous geometric model, and is obtained by decomposing it into small elements having a simple but arbitrary size (the finite elements).

FEA ensures that design requirements are feasible. It can be useful both when designing a new product before its manufacturing and when refining an existing product, e.g., when creating a product design variant or when the original one is subjected to new loading conditions. In case of analysis failure, FEA may be used to determine which design modifications better meet the mechanical conditions.

A typical shape evolution cycle for FEA is illustrated in Fig. 3. The CAD model used to design the product (Fig. 3(a)) is usually represented by parametric surfaces, which are suitable for manufacturing purposes, but not for performing a FEA. Therefore, the initial design model generated by a CAD system needs to be converted into a FE mesh.

Actually, the FE mesh is generated on a simplified model of the component (Fig. 3(b)). In fact, the initial one usually contains several shape details which complicate and could compromise the FE mesh generation and solving. Therefore, several steps of shape adaptation are required, where the shape details (e.g., form features) considered as not influent on the FEA have to be removed. However, shape simplifications performed on the design model could affect the accuracy of FE results. Their choice and evaluation have to be carefully analysed and require significant expert knowledge. Once the FE mesh is created on the simplified shape, boundary conditions are added (Fig. 3(c)).

They describe the interactions of the component with its neighbouring environment (e.g., forces, displacements, temperatures over defined model's areas) and are related to the specific mechanical problem to be studied, e.g., structural mechanical, electromagnetic, thermal analysis.

Then, the FEA is executed (Fig. 3(d)). It returns information about the behaviour of the component when subjected to the loads and constraints specified by the boundary conditions (Fig. 3(e)). The kind of information included in the simulation results depends on the type of physical problem that has been simulated. For example, a thermal analysis can return information about temperatures, while a structural mechanical analysis can provide a stress field as a possible result.

To address engineering analysis in the PDO, we considered two different user scenarios. The first focuses on the removal of shape details when generating a simplified version of the design model. A user could be interested in testing tools, able either to suppress shape details during the simplification of the initial design model or analyse the influence of the performed shape simplification on FE simulation results.

The second scenario is related to the post-processing stage. Indeed, behaviour simulation results need to be post-processed for interpreting the simulation outcome and making decisions about the suitability of the design with respect to its engineering specification. The first post-processing phase is a check on the occurrence of numerical problems during the solving. If they did not occur, the entities of interest may be examined thanks to interactive visualisation techniques supporting the FEA.

Similarly to the freeform scenario, a user working in the area of FEA may seek for relevant shapes, possibly real-world test data contained in the DSW. In addition, searching for alternative tools is useful for benchmarking in both pre-and post-simulation scenarios. In an industrial context, these scenarios can be interpreted as the retrieval of past successful company projects and the analysis of such projects for further reuse or training.

Examples of CQs related to the engineering analysis scenarios are: find the tools that perform Meshing and have as input a design model with format STL and have as output a Volume Mesh; find the models suited for a FEA; find models that are simulation results of a thermal analysis applied to a cylinder head.

Grouping mechanisms

Several shape grouping mechanisms are adopted in Product Design. Gathering related models can be useful for their further reuse; for example, it is very common:

-Grouping shapes belonging to the same product category Still in the design phase, a new product is usually created drawing inspiration from or even reusing past design. In this case, a user needs to retrieve product models belonging to a particular category, e.g., the car light box.

-Grouping shapes belonging to the same assembly Complex products are not designed as single models: engineers, especially in the automotive and aerospace industry, rather separately design the different parts and assemble them in a second phase.

-Grouping shapes representing the same object in different representations and different formats Generally, this kind of grouping is useful when passing from one PDP stage to another, where models need to be transferred to other systems or converted into other geometric representations.

-Grouping shapes belonging to specific chains of shape processing operations

In PDP, typical sequences of operations can be identified when performing certain tasks.

Consequently, a shape workflow can be recognised, where one shape derives from the previous one after the application of suitable tools. A user may need to retrieve such workflows to interpret and better evaluate the shape under examination. In particular, models of a specific workflow can be searched for; it can be also useful to find out if a given model belongs to different workflows. For example, the grouping of different simplified versions of a model needed during a FEA preparation can support an engineer in a post-processing task.

According to the identified categories of groups, here is a list of CQs that imply the use of some notion of group: does a given model belong to an analysis group? does it belong to an assembly? does it have a design variant in the repository? find all the elements of a given group.

PDO: The Product Design Ontology

The PDO was modelled according to On-To-Knowledge [START_REF] Sure | On-To-Knowledge Methodology[END_REF], a widely used methodology for ontology development which, at the time of the project, was optimal in terms of power of capturing knowledge domain and simpifying the process of ontology formation.

Few methodologies tailored to product design have emerged recently; for instance, in [START_REF] Nanda | A Methodology for Product Family Ontology Development Using Formal Concept Analysis and Web Ontology Language[END_REF] a formal methodology has been proposed, which, whilst is well structured, is very targeted towards product families rather than shape processing in product design.

On-To-Knowledge does not refer to a specific domain, but may be classified as an applicationdependent methodology [START_REF] Corcho | Methodologies, tools and languages for building ontologies. Where is their meeting point?[END_REF]. It defines the ontology design and deployment as an interative process including four phases: kick-off, refinement, evaluation, and maintainance and evolution.

During the first step of the kick-off phase, the key concepts and their mutual relations were identified, together with the usage scenarios we described in Section 2, knowledge sources (domain experts, glossaries and dictionaries, etc.), potential users, and the competency questions the ontology would have answered. In the second step, a semi-formal hierarchy of concepts and relations was built by applying a middle-out approach: the most important concepts were identified, while the others were defined either by their specialisation or generalisation. This a very natural approach, which permits to focus on the core concepts and select the level of detail desired for the formalisation.

In the refinement phase, we modelled the formal product design ontology using Protégé (Protégé) in combination with the corresponding OWL plug-in. We chose OWL to model the PDO because, differently from other technologies, e.g., the Resource Description Framework (RDF), it provides an improved expressive power for representing (formal) machine-interpretable semantic content. Hence, it allows to represent effectively relationships and modelling constraints among the conceptual entities that describe the Product Design domain. In particular, the use of OWL allowed us to model cardinality restrictions on data properties and subproperties, as well as to define further inference rules on relations. For instance, the object properties hasPredecessor and hasSubTask of the concept Task in Fig. 4 are declared as transitive properties.

During the evaluation phase, the ontology was populated and constantly validated to measure its compliance with the initial expectations. Usage scenarios, requirements specifications and CQs were used as a reference for the evaluation.

Finally, the mantainance phase took into account the evolution of the ontology according to refined application scenarios.

Guarino proposed in [START_REF] Guarino | Formal ontology and information systems[END_REF] to develop different types of ontologies to capture knowledge at various levels of detail. In accordance with this work, the two Common Ontologies from the AIM@SHAPE network (cf. Section 1) may be referred to as domain ontologies. In fact, the COs model the generic concepts of shape representation and shape processing tool, which strongly intervene in the previously described scenarios. The PDO specialises those concepts according to the specific point of view of PDP actors, thus can be seen as an application ontology in the Guarino's classification.

The modelling process of the PDO we described above is also aligned with the specification, conceptualisation, formalisation, implementation and evaluation phases specified by METHONTOLOGY (Fernandez, 1997), even if it does not rely on application scenarios.

The core components of the PDO are (see Fig. 4):

• shape types and shape representations with product design related metadata;

• shape processing tools and algorithms employed in the product design context;

• tasks accomplished by software tools applied to shapes, which are both data sources and results of product design tasks along the product design flow;

• conditions, either geometric or not, which are related to a shape model when performing a specific task;

• groups, which permit to gather together digital models that share some interrelation. In the following, we focus on the PDO peculiarities, and the choices related to the ontology design are discussed with respect to the specific requirements of the freeform and analysis scenarios. In particular, the different tasks involved in the Product Design workflow have been formalised, together with the different roles a shape can play within the shape life-cycle (e.g., the input and output of the simulation task are surface or volume meshes enriched with proper simulation data and properties), and the requirements and conditions a shape must or should satisfy to fulfil a given task.

The Task Concept

The Task concept (see Fig. 4) is the central unit of any pipeline within the PDP and is strictly connected with shapes and tools. Each instance of Task represents an activity in the PDP, which involves the application of shape processing tools on some shape model. An example of task is simulation post-processing, as discussed in Section 2.

Task is provided with four auto-relations to model any sequence of tasks constituting a specific process or process step in the PDP. The link with software tools is modelled with specific relations,

which enable the answer to some of the competency questions discussed in the previous section (e.g., search for tools that check the connectivity between patches of the CAD model). Note that we are able to distinguish among the different functionalities a tool provides, thus retrieving categories of tools, e.g., freeform modelling tools.

The role of a shape: ShapeRole and PDModel

The scenarios described in Section 3 demonstrate that, when performing a specific activity of the PDP, i.e., a task, the digital representation of the shape is always equipped with additional contextdependent information. The concepts of ShapeRole and PDModel have been introduced to model respectively shape types and shape representations, enhanced with extra data, for instance regarding conditions to be applied on the shape to fulfil the task activity.

The ShapeRole concept enriches shape types description (e.g., volume mesh, BRep) with additional information intervening in a specific task of the Product Design workflow. It is particularly useful for inexperienced users, because it provides the user with all the expertise necessary to execute the whole development process. For each task in the PDP, the user can learn about: the shape type required; the conditions to be verified in order to complete it; the type of results returned and the additional information provided. In particular, ShapeRole gives the input and the output shape type for a task.

Moreover, it enables the retrievement of the domain knowledge about specific shape processing workflows, answering CQs like: find the types of model needed as input of a simplification task. These concepts are employed by the simplification and FEA tasks, respectively. The consistency of the different roles has been maintained: for example, a FiniteElementMesh is restricted to have a surface of volume mesh as a shape type, together with suitable boundary conditions. The concept FiniteElementMesh is further specialised through the concepts PreSimulationMesh and PostSimulationMesh in order to distinguish between the two different roles a mesh can play in the context of simulation. Differently from ShapeRole, which models the role of a given shape type, the PDModel (Product Design Model) concept (see Fig. 6) has been introduced to model the role of a specific shape model.

In fact, while the concept of shape role is useful to find general pipelines in the PDP, the PDModel permits to retrieve the flow of a single shape. Thus, it assists the benchmarking and testing activities of specialised researchers on the one hand, and, on the other hand, it provides engineers with the histories of specific digital products. Consistently, a PDModel also includes the information related to the corresponding shape role.

PDModel is currently implemented through the concepts SimplificationModel, representing the models occurring in simplification, and SimulationModel, employed in FEA. The corresponding roles are SimplificationModelRole and FiniteElementMesh, respectively (cf. Fig. 5).

A PDModel includes also the information about the CAD features occurring in the model representation. Indeed, when retrieving CAD models as test data, the presence of metadata about features is a clue to the complexity of the model. The occurrence of each type of feature, e.g., hole and blend, is reported (Fig. 6).

Fig. 6. The PDModel taxonomy and some of its relations

The Condition Type

As mentioned above, the concept ShapeRole specialises shape types related to a specific task of the Product Design workflow. This specification includes information about the conditions a shape of the corresponding type has to satisfy in order to perform that task, hence modelled through the concept ConditionType (Fig. 7). The introduction of the ConditionType class makes it possible to answer to competency questions like: find the types of geometric conditions that are necessary for a FEA.

Several types of conditions can be used for enriching a shape, that is, characterising a shape role. We concentrated on geometric conditions, which have been further specialised to distinguish the geometric properties applying to different shape types (so far, BRep and Mesh), and boundary conditions, which are associated to a mesh during the analysis stage (see Fig. 7). the geometric conditions that a shape with the given ShapeRole must or should verify. This property is further specialised through sub-properties (see Fig. 8) to distinguish between conditions specifically related to the shape type (e.g., conformity, a condition required to a mesh when its shape role is FiniteElementMesh) and to the task while performing it. The conditions related to the task can be either geometric (e.g., edge size), as in case of simplification tasks, or not (e.g., boundary conditions), as it happens, for instance, when performing simulation. Moreover, a further distinction is made to discriminate between conditions that are mandatory for a given role and conditions whose verification is suggested (namely, necessary and preferable conditions, respectively).

Modelling groups

The modelling of the Group class enables the creation of a relation between product models of a repository, which have not been stored together. The property hasElement has values in PDModel and

is invertible to answer to CQs asking for retrieving groups for a given element, like: find the simulation model whose role is PreSimulationMesh and that belongs to an analysis group also containing the post-simulation model of the given one.

The Group class has the subclasses AssemblyGroup, VariantGroup, SimplificationGroup, and AnalysisGroup, which correspond to the categories of the groups we introduced in section 2.3 (see Fig. 9). Finally, the AnalysisGroup aims at structuring the different PDModels related to the simulation phase, requiring that at least one SimulationModel belongs to such group. The AnalysisGroup specialises the relation hasElement with the subproperties hasDesignModel, hasTessellatedModel, hasSimplificationModel, hasPreSimulationMesh, hasPostSimulationMesh, so that the shape workflow is implicitly modelled and its retrieval becomes easy for the user, once he/she browses the group. The structure of the PDO can also be navigated through a hyperbolic tree. Such viewer allows the user to familiarise with the ontology showing only the class herarchy. Moreover, it is possible to browse directly the metadata that are associated to the ontology instances. Figure 12 shows an example of metadata browsing, where the user begins his/her navigation by searching for an instance of analysis group and then, starting from the obtained results, goes on looking for the metadata related to it. A mechanical assembly is selected from the shape repository to perform a structural simulation on one of its components. The mechanical component changes role according to the specific subtask, which constrains the conditions on the shape data to be verified. At the beginning of the workflow, it is an instance of the concept SimulationModel, which is associated with a BRep model in the shape repository; it has the role of SimplificationModel because some details have to be removed before the Meshing task. After meshing the geometric model, the role of the mechanical component becomes PreSimulationMesh, because it has to be subjected to a simulation process.

Knowledge about the workflow can be gathered both by browsing metadata, as showed in Fig. 12, and by querying the semantic search engine. As an example, the mandatory geometric conditions to perform a FEA may be asked to verify if the mesh obtained is suitable. Fig. 14 shows the answer of the search engine to the CQ "which types of geometric conditions are necessary for a simplification model for analysis?". If the user wants to specialise more his/her query on some constraints that have to be respected during the simplification process, he/she can browse the instances of the ShapeRole SimplificationModelForAnaysis: for SimplificationMeshwithStaticBC, he/she will find that also AxisSymmetry, Translation and VolumetricForce are necessary task conditions. According to the kind of simulation, specific boundary conditions have to be applied in the task DefinitionOfBoundaryConditions, which are instances of BoundaryConditionType (StructuralMechanics, in this case). After performing the simulation, the output shape will be an instance of the SimulationMesh with the role of PostSimulationMesh: this implies that the simulation results are associated to the geometric part in order to interpret the simulation outcome and to make decisions about the design suitability with respect to its engineering specification.

Conclusions

In this paper, an ontology-based formalisation of the Product Design Process has been presented.

Herein we focussed on the Product Design workflow, introducing the role of shapes along such workflow and the geometric and the task-oriented conditions involved in the process. The formalisation also includes the representation of the functionality of shape processing methods.

The main effort of this work has been put into designing a flexible and rich ontology scheme, capturing and sharing the knowledge related to the digital shape workflow that is typical of the first phases of PDP.

Although the PDO target was initially the research community, we believe that such a formalisation can be also reused and extended according to industrial requirements, coupling it with the project repository of the company. In fact, an effective retrieval of past solutions and the training of companyspecific processes are definitely a key issue of the digital product design phase.

The main limitation of this work is that the semantic annotation required to populate the ontology is performed manually; thus, enriching the model repository becomes an expensive activity. This aspect is even more critical in an industrial context, where past projects are numerous and their storage is different according to the company policy, possibly changing over the years.

Automatic annotation of resources is related to the development of advanced tools and search engines able to deal with such new data, which is an open issue in semantic web and related areas. In the AIM@SHAPE project, the geometric aspect has been tackled developing different automatic annotation tools in the DSW [START_REF] Borgo | Extracting Meta-Information From 3-Dimensional Shapes With Protégé[END_REF], able to extract useful information from a specific digital shape and to translate it according to the metadata defined in the Common Shape Ontology.

Similarly, some automation is predictable for the PDO, still referring to the morphological and topological aspect. In fact, several research results related to the automatic extraction of the assembly and feature information from the model evaluation are present in literature. There exist techniques that aim at extracting automatically the assembly graph from a complex model (see, for example, http:// www.cadshuttle.org), while feature recognition methodologies are well-known and widely applied in product design.

On the contrary, the PD domain knowledge treated in this paper cannot be automatically extracted.

Nevertheless, if we consider the adoption of the proposed methodology in industry, the amount of manual annotation may be limited to the annotation for each single project, once the company repository is structured according to the semantic conceptualisation proposed in the PDO.

More generally, the efficacy of new methodologies for 3D shape modelling and reasoning relies on an effective coupling between geometry and semantics. Such a goal should be obtained minimising the interaction between the user and the system, which has several margins of improvements in all the application areas where standardised procedures exist and can be identified and extracted. Therefore, a closer collaboration with the users for the collection and exploitation of the knowledge is needed in order to encode the semantics and enrich the intrinsic information of the product within the various contexts of the product design.

Fig. 1 .

 1 Fig. 1. Product Design Flow as modelled in the ISO 10303, AP214 (STEP)

Fig. 2 .

 2 Fig. 2. Description of the scenario for the freeform modelling task.

Fig. 3 .

 3 Fig. 3. Shape life-cycle in a typical FEA design evolution loop.

Fig. 4 .

 4 Fig. 4. PDO core concepts

Fig. 5

 5 Fig. 5 shows the complete ShapeRole taxonomy provided by the current version of the PDO. Two direct implementations of ShapeRole are included: SimplificationModelRole and FiniteElementMesh.

Fig. 5 .

 5 Fig. 5. The ShapeRole taxonomy.

Fig. 7 .

 7 Fig. 7. ConditionType taxonomy

Fig. 8 .

 8 Fig. 8. Relation hasCondition and its subproperties

Fig. 9 .

 9 Fig. 9. Groups in the PDOThe AssemblyGroup has the restriction that any subgroup contained is an assembly. It is also possible to specify the graph structuring the assembly components through the relation hasStructuralGraph. This allows the user to manage complex assemblies and easily retrieve information about the interrelationships among the assembly components.The VariantGroup includes few variants of the same model; in particular, we took into account the concept design variants and format variants.The SimplificationGroup concept specialises the general Group class with the constraint of containing at least one SimplificationModel. A SimplificationGroup gives the possibility of collecting both different simplifications of the same model and models having a different ShapeRole. Indeed, the group contains models linked together in a simplification workflow, no matter what their shape role is, as required by the identified user scenarios.

Fig. 10 .

 10 Fig. 10. AIM@SHAPE Semantic Search Engine

Fig. 12 .

 12 Fig. 12. An example of metadata navigation Besides simple searches and navigation through ontology classes and metadata, the user may use the SSE in order to ask precise queries to the PDO. In Fig. 13, a typical usage scenario of the PDO within the DSW is shown; it is related to the task Calculation and Analysis, further specialised in several subtasks describing the different simulation activities (e.g., Shape Simplification, Meshing, Definition of Boundary Conditions).

Fig. 13 .

 13 Fig. 13. An example of simulation workflow

Fig. 14 .

 14 Fig.14. Results of the graphical query

Acknowledgments. This work has been carried out within the scope of the AIM@SHAPE Network of Excellence supported by the European Commission Contract IST 506766. The work of Elena Camossi is supported by the Irish Research Council for Science, Engineering and Technology. The authors are grateful to the AIM@SHAPE partners, in particular they would like to thank Tor Dokken 26 (SINTEF), Gino Brunetti (IGD), Jean-Claude Leon (INPG), Franca Giannini (IMATI), Marios Pitikakis (ITI) for their active contribution to the PDO development.

4

The PDO in use

The structure of the PDO has been validated as part of the DSW of the AIM@SHAPE Network of Excellence, both evaluating its semantic correctness and verifying its effectiveness. The first assessment has been done by the researchers involved in the project, who also tested the effectiveness in answering all the CQs of the selected scenarios through the project web portal (AIM@SHAPE).

For this purpose, an on-line Semantic Search Engine (SSE) has been developed within the network (see Fig. 10), providing the means for intuitive search, without dropping the flexibility or expressiveness of the queries. This is accomplished by letting the user interact with the underlying knowledge base rather than simply querying, by using both a graphical user interface and the natural language. The semantic-based natural language query interface of the SSE is able to analyse semantically queries using ontologies and to provide adequate results. In Fig. 10 the user submits the natural languange query Find a simulation model which role is a post simulation mesh. Fig. 11 shows the corresponding results, indicating that there are some instances of the concept SimulationModel that have the link hasShapeRole to some instances of the concept ShapeRole.