Jullius Cho
email: jullius.cho@tuwien.ac.at

Thomas Vosgien
email: thomas.vosgien@v-research.at

Thorsten Prante
email: thorsten.prante@v-research.at

Detlef Gerhard
email: detlef.gerhard@tuwien.ac.at

KBE-PLM Integration Schema for Engineering Knowledge Re-use and Design Automation

Keywords: Knowledge-Based Engineering, Design Automation, Knowledge re-use, Design Intent, Design Rationale

scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

As part of the implementation of PLM strategies, contemporary computer-based tools should provide engineers with means to better handle the processes involved across the product lifecycle. Within this context, there is considerable pressure on engineers to improve their product development processes in order to deliver complex and high-quality products and services to the market rapidly and at low cost [START_REF] Brown | Product Development: Past Research, Present Findings, and Future Directions[END_REF]. One approach to achieving this improvement is engineering design automation, where interdependent engineering design processes are subject to partial or full automation. If the focus of the automation is on repetitive tasks, this is called Knowledge-Based Engineering (KBE) [START_REF] Verhagen | A critical review of Knowledge-Based Engineering: An identification of research challenges[END_REF]. For its implementation, product and process engineering knowledge needs to be identified, acquired, formalized, processed and re-used. However, on the one hand, knowledge acquisition is still a bottleneck and, on the other hand, the formalized engineering knowledge is too often encapsulated in CAD models and inference engines of KBE systems, which are not easily accessible outside vendor-specific application environments. Thus, re-use of formalized knowledge across KBE applications, and even within the same KBE application across time, is an issue. This is reflected in the following shortcomings of KBE as identified in [START_REF] Verhagen | A critical review of Knowledge-Based Engineering: An identification of research challenges[END_REF]: First, case-based, ad hoc development of KBE applications, second, a tendency toward development of 'black-box' applications (i.e. formalized knowledge is not explained or contextualized, so not related to design intent -with some exceptions such as [START_REF] Kim | Standardized data exchange of CAD models with design intent[END_REF]) and, third, generally, a lack of knowledge re-use is observed -where these three reported shortcomings are interrelated. Compared with this, PLM support entails the modeling, capturing, manipulating, exchanging and using of information all along product life cycle decision making processes, across all application domains [START_REF] Rachuri | Information sharing and exchange in the context of product lifecycle management: Role of standards[END_REF]. Therefore, a strong focus of a PLM strategy should be on knowledge re-use and it doesn't come as a surprise that integration of KBE and PLM systems has been identified to provide advantages ( [START_REF] Catic | Towards Integration of KBE and PLM[END_REF], [START_REF] Bermell-Garcia | Practitioner requirements for integrated Knowledge-Based Engineering in Product Lifecycle Management[END_REF]) for product development. For instance, the following deficiency could therewith be overcome: Although many CAD systems provide basic design automation capabilities which allow parts, assemblies, and drawings to be parametrically generated and changed, the capabilities for consistent changes to product configurations generally remain restricted because knowledge in repositories of KBE systems is not linked to the product information/definition managed in PLM systems [START_REF] Catic | Towards Integration of KBE and PLM[END_REF]. Still, there are major challenges for overall KBE-PLM integration and its interoperability enabler: one, the "ability to unlock engineering knowledge from proprietary representations" and, two, the ability to manage the lifecycle of KBE models" [START_REF] Bermell-Garcia | Practitioner requirements for integrated Knowledge-Based Engineering in Product Lifecycle Management[END_REF]. Overcoming these challenges will result in improved support for the development and maintenance of KBE systems for design automation and hence for the overall engineering design process efficiency. In this paper, we propose a KBE-PLM integration framework enabling to retrieve and integrate the information and knowledge from CAD, KBE and PLM systems in order to store and manage them in a platform independent Open KBE repository structured according to the KBE-PLM integration schema. The goal is to be able to re-use this knowledge for different KBE applications for design automation. Section 2 discusses relevant background and state of the art. The architecture of the framework and the KBE-PLM integration schema are presented in section 4 and discussed in section 5, before concluding the paper and presenting lines of possible future work.

Background

Product Knowledge, Design Intent and Design Rationale

There are several methodologies which have been developed and/or used for the design, development and deployment of KBE systems, such as MOKA [START_REF] Stokes | Managing engineering knowledge: MOKA -methodology for knowledge based engineering applications[END_REF], CommonKADS [START_REF] Schreiber | Knowledge engineering and management: the CommonKADS methodology[END_REF], and KNOMAD [START_REF] Curran | A multidisciplinary implementation methodology for knowledge based engineering: KNOMAD[END_REF]. While most of them have addressed the issue of knowledge capture and structuring/formalization, none of them has yet integrated the concepts of design intent and design rationale to facilitate better re-use. According to [START_REF] Hoisl | Towards Representing, Evolving and Networking Engineering Knowledge for Computational Design Synthesis[END_REF], product knowledge includes function, structure and behavior models of an artifact along with product specifications, requirements, and constraints and includes various kinds of relationships between parts and assemblies [START_REF] Chandrasegaran | The evolution, challenges, and future of knowledge representation in product design systems[END_REF]. This definition is in line with the Function-Behavior-Structure (FBS) framework proposed by [START_REF] Gero | The situated function-behaviour-structure framework[END_REF]. In [START_REF] Chandrasegaran | The evolution, challenges, and future of knowledge representation in product design systems[END_REF], the authors also include design process knowledge as part of the product knowledge, which can be encoded as methods in a product representation and provides mechanisms for realizing design details at various stages of the product lifecycle and in [START_REF] Hoisl | Towards Representing, Evolving and Networking Engineering Knowledge for Computational Design Synthesis[END_REF] process knowledge is defined as design rules, strategies, automated model mappings, analysis scripts and problem-solving algorithms. In making the connection between product and design knowledge on the one hand and design intent and design rationale on the other, it must be noted that there is some ambiguity regarding the definitions of the two later terms [START_REF] Chandrasegaran | The evolution, challenges, and future of knowledge representation in product design systems[END_REF]. While design intent is captured in a set of functional and non-functional requirements, the design rationale encapsulates both the semantics and conditions for all the mappings and transformations from requirements to architecture (i.e. structure) [START_REF] Gerhard | IT-Based Configuration and Dimensioning of Customer Specific Products -Towards a Framework for Implementing Knowledge Based Design Assistant Systems[END_REF]. Thus, design rationale relates to and describes the process of designing ('design logic') and is related to the design intent which represents the reason(s) that justify design decisions. In this paper, design intent and rationale will be defined as follows (see section 3.2): design intent is a concept that, based on a specific usage context, enables one to know which product structural representation and related design rationale to use to fulfill a specific functional intent. Design rationale refers to the design rules, automated model mappings, analysis scripts and problem-solving algorithms required to fulfill a specific intent.

Model-Based Definition (MBD) and KBE-PLM Systems Integration

The central concept embodied in MBD is that the 3D product model is the most appropriate vehicle for delivering all of the detailed product information necessary for downstream organizations to perform their portion of the product creation [START_REF] Quintana | Will Model-based Definition replace engineering drawings throughout the product lifecycle? A global perspective from aerospace industry[END_REF]: CAD models are enriched with explicit and implicit knowledge which needs to be extracted, formalized and managed for re-use in different contexts. However, extracting knowledge encapsulated in CAD models remains a challenge. Gerhard and Lutz [START_REF] Gerhard | IT-Based Configuration and Dimensioning of Customer Specific Products -Towards a Framework for Implementing Knowledge Based Design Assistant Systems[END_REF] propose a knowledge acquisition and knowledge formalization assistant (KAFA) which employs the design structure matrix technique to capture product knowledge directly from CAD models and enable experts to formalize the design logic. Using CAD models as the main container of product knowledge stresses the necessity to be able to extract and re-use this knowledge in heterogeneous environments such as KBE and PLM systems. However, current MBD approaches do not address the development of neutral product data representations which enable links between representations of product definition, design intent and design rationale. Combining both MBD and KBE-PLM approaches is required to efficiently encapsulate design knowledge in CAD models and at the same time to extract the knowledge for re-use in faster platform-independent KBE systems development or in the appropriate design context and related activities.

KBE-PLM Systems Interoperability

An example of a standardized modeling framework is the Model-Driven Architecture (MDA) for portability, interoperability and reusability between IT systems [START_REF]Object Management Group[END_REF]. In order to achieve integration and interoperability, transparent access to proprietary data and services is needed. Moreover, a neutral representation of product information will help to increase interoperability. Truyen [START_REF] Truyen | The Fast Guide to Model Driven Architecture The Basics of Model Driven Architecture[END_REF] addresses these concerns and specifies three default viewpoints on a system: computational independence, platform independence and platform specific models. Correspondingly, the framework proposed in this paper (section 3), needs to be CAD, PLM and KBE systems independent. Thus, we have considered the following:

 Neutral product data representations to ensure data interoperability between CAD and PLM systems.  Neutral knowledge representations to ensure the interoperability between KBE systems.  A CAD abstraction layer enabling managing multi-CAD APIs giving access to the various CAD systems capabilities and enable inference engines to be CAD independent.

There are works dedicated to the exchange of data between CAD and PDM systems as well as the exchange of CAD and configuration data information between KBE and PLM systems such as [START_REF] Pablo | Towards the Semantic Interoperability Between Kbe and PLM Systems[END_REF]. The Standard for the Exchange of Product Model Data (STEP)1 covers many aspects of product data exchange in the context of product development. The emerging STEP Application Protocol (AP) AP242 [START_REF]Industrial automation systems and integration -Product data representation and exchange -Part 242: Application protocol: Managed model-based 3D engineering[END_REF] merges AP203 and AP214 which are currently the most implemented for CAD data exchange between existing commercial CAD systems. The PDM Schema is a core set of entities in STEP that support the mapping of concepts for Product Data Management (PDM) systems interoperability integrating different STEP generic and application resources among which Parts 41 (fundamentals of product description and support), 42 (geometric and topological representation), and 44 (product structure configuration). The transfer of associated geometric interrelationships, parameters, and constraints, which is of particular importance to our proposal and which is not yet implemented in any application, is addressed by the Integrated-Application Resource 108 [START_REF]Industrial automation systems and integration --Product data representation and exchange --Part 108: Integrated application resource: Parameterization and constraints for explicit geometric product models[END_REF] and also in [START_REF] Lee | Strategies for Using STEP in Parametric Design[END_REF]. In [START_REF] Vosgien | Model-based system engineering enabling design-analysis data integration in digital design environments: application to collaborative aeronautics simulation-based design process and turbojet integration studies[END_REF], the author proposes a multi-layer design analysis systems integration framework integrating various concepts defined in the aforementioned STEP AP and parts as well as concepts from other neutral product data representations such as the CPM [START_REF] Fenves | CPM2: a core model for product data[END_REF]. However, these endeavors have not solved the problem of being able to explicitly and unambiguously share geometric parameters and the design intent/design rational for knowledge re-use.

Concerning neutral KBE knowledge representations, some knowledge sharing initiatives in the beginning of the 90's have led to the implementation of some neutral knowledge formats in specific KBE applications such as the Knowledge Query and Manipulation Language (KQML) [START_REF] Finin | An overview of KQML: A knowledge query and manipulation language[END_REF] and the Knowledge Interchange Format (KIF) [START_REF] Genesereth | Knowledge interchange format-version 3.0: reference manual[END_REF]. However the adoption and implementation of these formats are restricted to few applications and their development and maintenance seem to have been stopped. More recently, the Rule Interchange Format (RIF) [START_REF] Kifer | Rule interchange format: The framework[END_REF] has been developed to enable knowledge representation and information processing on the Web.

Very few works can be found in the literature regarding the development of platform-independent KBE systems. However we can quote the recent work from [START_REF] Sanya | An ontology framework for developing platformindependent knowledge-based engineering systems in the aerospace industry[END_REF] in which authors propose a software framework using ontologies for representing design knowledge and for implementing platform-independent KBE systems within the aerospace industry. An essential element of the proposed framework and which will also be required for our framework is the use of APIs and GUIs that enables direct integration and communication between a KBE knowledge base, different CAD systems, GUI application and end-user.

Finally, in 2006, the Object Management Group (OMG) submitted a Request for Proposal for an international standard for KBE Services for PLM [START_REF] Fan | International Standard Development for Knowledge Based Engineering Services for Product Lifecycle Management[END_REF]. This standard intended to facilitate the integration of KBE applications in a PLM environment. To date, no answer to this RFP and no OMG specification for KBE services exist. This paper do not pretend to answer the request for proposal, but the framework and the schema presented in the next section could serve as a basis for future work in that direction.

3

The KBE-PLM Integration Framework and Schema

The proposed KBE-PLM integration framework presented in section 3.1 is a federated platform-independent KBE environment enabling to retrieve and integrate the information and knowledge from CAD, KBE and PLM systems in order to store and manage them in a platform independent Open KBE repository. The goal is to be able to re-use this knowledge for different KBE applications for design automation. It also ensures a reintegration of the KBE-processed knowledge within various PLM systems repositories for further re-use in downstream design activities. Considering an MBD approach for supporting KBE-PLM systems integration, we assume that most design knowledge and related design rationale (design logic) are encapsulated respectively in CAD models and in KBE systems inference engine scripts. The Open KBE repository is structured according to the KBE-PLM integration schema introduced in section 3.2. This schema depicts a concept for representing in a neutral way a configured product definition, the explicit knowledge encapsulated in parameterized CAD models and the implicit knowledge related to the design intent and rationale of these models.

Architecture of the KBE-PLM Integration Framework

The KBE-PLM integration framework architecture, shown in Figure 1, has been specified using the open enterprise modeling standard ArchiMate [START_REF] Lankhorst | The architecture of the archimate language[END_REF] developed by The Open Group. The framework mainly comprises a Transformation Engine including a Multi-CAD API Manager, an Open KBE Repository (the server), and an Open KBE Client. 'Open' is used in the sense of neutral. The transformation engine encompasses a set of translator libraries. These enable the transformation of native data inputs extracted from PLM system (such as PDM and ERP systems) as well as from KBE systems. The nature of these inputs will depend on the addressed use case scenarios that the framework will support. The goal of the translators is to make these inputs compliant with the proposed KBE-PLM integration schema. Once the data inputs are transformed according to the schema, they can be stored in the Open KBE Repository and be interpreted and processed by the other framework components. For instance, the product structure and knowledge encapsulated in CAD parameterized assembly models can be extracted with the help of the Knowledge Acquisition and Formalization Assistant (KAFA) [START_REF] Gerhard | IT-Based Configuration and Dimensioning of Customer Specific Products -Towards a Framework for Implementing Knowledge Based Design Assistant Systems[END_REF]. KAFA automatically reads the structure, components and parameters of a CAD model and generates a component-parameters design structure matrix (DSM). It extends the functionality of DSM methods by providing simple and intuitive means to enable the engineer to formalize the configuration and design logic in textual and executable forms. The component and parameter dependencies and formalized rules defined in KAFA should enrich the Open KBE Repository according to the schema. The Open KBE client includes a user interface (UI) to access and request the Open KBE repository as well as a configurable 3D visualizer enabling to display the CAD geometry with the "fit-for-purpose" information (dimension, tolerances, parameters, rules, etc.). This UI should enable framework users to drive the required transformations for:

 translating the instantiated KBE-PLM Integration Schema and related reasoning models so that they can be processed by the right inference engine;  driving the automation procedure in the appropriate CAD system through the use of the Multi-CAD API Manager;  translating the outputs of the inference engine into the appropriate format so that new product definitions can be reintegrated in the various PLM systems.

The KBE-PLM Integration Schema

The KBE-PLM Integration Schema is an abstract model with system-independent and language-independent semantics. The schema defines a neutral product data and knowledge representation enabling the exchange of parameterized CAD assembly models and related design intent and rationale. It also associates the geometric representation and rationale to a specific usage context integrating information such as configuration management data, version history and the KBE application that process the design rationale. Figure 2 shows a Unified Modeling Language (UML) class diagram of the top abstraction level of the KBE-PLM Integration Schema. The structure of the schema is aligned with the modeling principles defined in STEP integrated and generic application resources and is also based on the premise that a product artifact has a form, a particular function and a behavior. The Product Model is the base abstract class for all entities that constitute the definition of a product. It is a master model containing data common to all configurations and versions of a system constituent. One Product Model has one or more Product Definitions and represents an abstract entity gathering all the characteristics and design information of a Product Model. The three Product Definition sub-types which are Functional Definition, Structural Definition and Behavioral Definition respectively gather the product functional variables, structural design variables and behavioral features of a Product Model.

Fig. 2. KBE-PLM integration schema -Top abstraction level.

A Product Definition consists of a set of Product Definition Representations (e.g. CAD models) and properties (e.g. mass and material properties). The product definition relationship entity enables to set up different types of relationship (dependency, hierarchical, etc.) so as to have traceability and consistency between the functional, structural and behavioral definition of a component. The Design Intent is a concept that, based on a specific usage context (defined by the Usage Scenario entity), enables the designer or engineer to know which product structural representation and related design rationale to use to fulfill a specific functional intent. The functional intent (defined by the Component Function Assignment Relationship) allows linking one Functional Definition to one Structure Definition to know what are the functions and related design requirements this structural definition intends to fulfill. Concretely, the design intent allows linking a specific Product Definition Representation to a specific Design Rationale and the related KBE application that can process it. Figure 3 shows a more detailed level of the schema depicted in Figure 2, focusing on instantiations of some of the abstract classes directed at:  representing a parameterized CAD assembly model;  representing the KBE rules through the use of the abstract class Variational Representation Item, the instances of which are the Parameters and Explicit Constraints defining the mathematical functions between parameters;  defining the specific relationships between a geometric model and its topological elements, its design rationale, functional requirements and design parameters.

To represent an assembly model an Assembly Component Usage (sub-type of Product Relationship) describes which components are present in each parent assembly component as well as its relative Position. A Structure Definition also aggregates a set of Properties class which can be Item Property or Shape Dependent Property. The Structure Definition also aggregates Structure Model(s) which is an abstract class defining various models derived from the Structure Definition. In Figure 3 below, only the Geometric Model is considered. A Geometric Model is an aggregation of Geometric Representation Items (topological element of the CAD model). In the STEP and Feature Based Parametric Modeling paradigms, the Geometric Representation Items are driven by parameters and constraints. In this schema the constraints (represented by the Explicit Constraint entity) define the dependency rules and the mathematical functions (as defined in ISO10303-50) between Parameters. In the above schema, there is a complex but necessary inheritance structure to manage and link these Geometric Representation Items to their related parameters and constraints. This inheritance mechanism is necessary to further extend the schema and to define constraints and/or rules between other types of parameters and product definition representation items from other types of product definition representations (behavioral representation or item property representations). The Geometric Representation Item entity and the Variational Representation Item entity are direct sub-class of the Product Definition Representation Items (which are the constituting elements of a representation whatever its type). The Parameter and Explicit Constraint entity are both sub-types of the Variational Representation Item entity. The abstract Explicit Constraint entity links a set of constant and variable parameters. The Explicit Geometric Constraint entity is the "instantiable" sub-type for linking a set of constant and variable CAD model parameters that are related to the some topological elements (Geometric Representation Item) of the CAD model.

Finally to integrate configuration context information with the Product Definition and its Design Intent, the proposed KBE-PLM integration schema is actually a multilayer schema as the one defined by Vosgien [START_REF] Vosgien | Model-based system engineering enabling design-analysis data integration in digital design environments: application to collaborative aeronautics simulation-based design process and turbojet integration studies[END_REF]. As shown in Figure 4, it integrates a system definition layer and a configuration layer in order to be able to ensure the interoperability with PDM systems through standardized data exchange. A Configuration is a product variant (or Configuration Item in ISO10303-44), i.e. the identification of a particular variant of a product. A product variant is defined with respect to the product class (product concept in ISO10303-44), i.e. the class of similar products of which it is a member. Concretely, Figure 4 shows the data model enabling to build, capture and modify the various product configurations and how they are linked to their constituting elements (Assembly Component Usage of Product Definitions) through the concept of "Effectivity". Effectivity is the key concept for linking the system Product Definitions to the appropriate product configurations in which they are valid as defined in . Instances of Effectivity may be applied to any Product Definition instances (or Assembly Component Usage). The View_Definition_Context defines the context in which the Product Definition of a product model is valid. A View Definition Context is the grouping of a Configuration_Context (defining the application domain(s) and the life cycle stage(s) in which a Product Definition is valid). In order to specify the usage and potential re-use of a representation with a design rationale in a specific configuration context, the Design Intent entity is linked to one Usage Scenario which refers to at least one View Definition Context Definition.

Summarizing, the core contribution of this schema is built on the Design Intent entity and its instantiation for CAD models (the CAD Design Intent) defining the proper defined relationships between a CAD model, its design rationale and its KBE usage scenario.

Discussion

The KBE-PLM integration framework and schema have been presented above. The schema has to be enriched with all Geometric Representation Item sub-types in order to be able to represent and exchange any kind of geometric model. The construction history has not been taken into account yet in the schema but will have to be addressed in future work. The feasibility of implementing such a data model will be demonstrated in future work addressing several test cases (see next section). With respect to the implementation of the framework components, we face some heavy refactoring work based on a number industry-strength prototypes of configurators and design automation systems developed by V-Research in earlier and current industrial research projects as part of COMET ProDSS [START_REF] Frank | Towards a Generic Framework of Engineering Design Automation for Creating Complex CAD Models[END_REF] and AEDA K-Projects (see below). We also have a KAFA prototype from TU Wien, and the neutral CAD-model representation is part of the first author's PhD project. The Multi-CAD API Manager is already operational with bidirectional interfaces (at different maturity levels) to three major CAD systems and was developed by V-Research.

The major limitation of the presented approach is the need to develop a large set of interfaces for CAD/KBE/PLM systems to incorporate them into the framework. Moreover, any evolution in these systems will entail adapting these interfaces to the evolved systems, e.g. CAD systems and their APIs. Thus, for full-potential leverage, standardization initiatives would be important in order to involve industrialists and software vendors in the development of the standard and in the implementation and maintenance of these interfaces. That is why the proposed KBE integration schema could serve as a basis to re-launch research work targeted on answering the OMG request for proposal "KBE services for PLM". Additionally, it could be used to demonstrate the feasibility of implementing ISO 10303-108 and be able to use this part of the schema in both PLM and KBE repositories.

Conclusion and way forward

The proposed KBE-PLM integration framework presented in section 3.1 is a federated platform-independent KBE environment permitting to retrieve and integrate the information and knowledge from CAD, KBE and PLM systems. The goal is to be able to re-use this knowledge for different KBE applications for design automation. It also ensures a re-integration of the KBE-processed knowledge within various PLM systems repositories for further re-use in downstream design activities. The framework encompasses a platform-independent Open KBE repository structured according to the KBE-PLM integration schema introduced in section 3.2. This schema depicts a concept for representing, in a neutral way, configured product definitions, the explicit knowledge encapsulated in parameterized CAD models and the implicit knowledge related to the design intent and rationale of these models. The work presented here only represents a starting point. The following issues will be addressed in future work. As mentioned, we are currently reviewing use-case scenario candidates and will correspondingly capture industrial test case (TC) datasets. These datasets will be used to demonstrate the feasibility to instantiate the proposed schema and implement such a platform-independent KBE repository generating a data base with the data model. Then a first client prototype will be developed to be able to enrich and request this database. Hence, KAFA will be extended to automate the extraction of the knowledge from the TC datasets, and the database will be enriched automatically. The Multi-CAD API Manager CADAL (CAD Abstraction Layer) is an ongoing development effort at V-Research.

Fig. 1 .

 1 Fig. 1. KBE-PLM integration framework architecture described in ArchiMate.

Fig. 3 .

 3 Fig. 3. KBE-PLM integration schema -CAD assembly models, CAD Design Intent, Design Rationale and Parameterization.

Fig. 4 .

 4 Fig. 4. KBE-PLM integration schema -Integration of configuration context information with the Product Definition and its Design Intent (adapted from [31]).

NB: To respect the length requirement of the paper, some of the mentioned parts of the ISO STEP standard are not in the reference list.

Acknowledgments. This work was supported by the K-Project 'Advanced Engineering Design Automation' (AEDA) that is financed under the COMET (COMpetence centers for Excellent Technologies) funding scheme of the Austrian Research Promotion Agency.


Joel Sauza-Bedolla

Carlo Rosso

Gianluca D ' Antonio

Paolo Chiabert

Vittorio Romagnoli
email: vittorio.romagnoli@polito.it

Industrial knowledge management tools applied to engineering education

Keywords: Knowledge management, engineering education, internal combustion engines,

Knowledge is a major source of competitive advantage. Hence, industry has developed tools to capture and reuse its knowledge in the development of new projects and products. Information practices and learning strategies, as Knowledge Management, are gaining acceptance also in the field of education. However, the use of these tools are limited to staff applications and they are not being employed in the university core business: education. This paper shows how a tool to build and validate internal combustion engines, developed in industry, has been successfully integrated into a university course. The learning process has being greatly enriched by the use of this application. Evidence on the planned improvements are also presented.

Introduction

The dynamism of the new market has created a competitive incentive among many companies to consolidate their knowledge assets as a means of creating value that is sustainable over time [START_REF] Gold | Knowledge Management: An Organizational Capabilities Perspective[END_REF]. Since knowledge resides within the brain of employees, firms have developed various strategies to create organizational knowledge through leveraging employees' knowledge [START_REF] Birasnav | Knowledge management and organizational performance in the service industry: The role of transformational leadership beyond the effects of transactional leadership[END_REF]. Among them, Knowledge Management (KM) involves any activity related to the capture, use and sharing of knowledge by the organisation [START_REF]Oslo Manual -Guidelies for collecting and interpreting innovation data[END_REF]. KM practices can include the handling of key documents, expertise directories, lessons-learned databases, best practices and communities of practice that reflect and deliver knowledge to learners at a particular time of need [START_REF] Bielawsky | Blended elearning: Integrating Knowledge, Performance Support, and Online Learning[END_REF].

The enterprise final objective is to build and deliver great products that customers are excited to buy. In the actual global conditions, companies have to fulfil many market requirements and some of them are in conflict with each other, for example car manufacturers have to design new engines with increased power that satisfy stricter pollution standards. Therefore, it is important to develop and validate, during the product conceptual phase, several product alternatives that take into account those conflicts and to select the optimal solution. The decision making process needs to be supported with IT tools.

In this contribution, the innovative principles of a tool to design and validate internal combustion engines are presented. The tool has been developed using a KM method in an industrial environment. Nonetheless, it is of primary importance to introduce automotive engineering students to the same industrial methods and to the use of the same tools. Therefore, the KM-based tool has be introduced in a university course.

The remainder of this paper is structured as follows: section 2 presents the revision of the state of the art of KM tools in industry and education. Next, the innovative principles embedded in the tool, Engine Paradigm (EP), are summarized in section 3. In section 4, a description of the activities necessary for the correct introduction of the tool in a university curricula is provided. The course deployment and results are discussed in section 5 and 6 respectively. Finally, conclusive remarks are discussed in section 7.

State of the art

KM is a trend topic and it has been extensively used in industry. There is evidence of its recent successful application in sectors such as aerospace [START_REF] Rocca | Knowledge-based engineering to support aircraft multidisciplinary design and optimization[END_REF], shipbuilding [START_REF] Hiekata | Cross-Domain Collaboration in Shipbuilding[END_REF], wind generation and naval engineering [START_REF] Ford | Knowledge Management: A Cross Sectorial Comparison of Wind Generation and Naval Engineering[END_REF]. In particular, KM has undoubtedly made strong inroads in the automobile industry [START_REF] Sukumaran | Knowledge Managementm in automobile: Application of a value chain approach using KM tools[END_REF]. In 2004 FIAT (now FCA Group) started a research to capture designer's knowledge in the first steps of engine concept design. The resulting tool, EP, is a knowledge driven accelerator conceived for developing diesel and gasoline engines.

Even if initially KM appeared to be adopted only in large, multinational and international companies [START_REF] Wong | Critical success factors for implementing knowledge management in small and medium enterprises[END_REF], now it has become the underlying source for successful organisations regardless of their size and geographical locations [START_REF] Okunoye | Where the global needs the local: variation in enablers in the knowledge management process[END_REF]. KM is beneficial in fields such as banking, telecommunications, production, manufacturing, and even the public sectors [START_REF] Omotayo | Knowledge Management as an important tool in in Organisational Management: A Review of Literature[END_REF]. There is even evidence of the use of KM in the management of cultural heritage [START_REF] Hervy | Co-working for knowledge management in cultural heritage: towards a PLM for museum[END_REF]. Among all these sectors, higher education institutions are exposed increasingly to marketplace pressures similarly to other industrial businesses. Hence, information practices and learning strategies, as KM, are gaining acceptance in education [START_REF] Petrides | Knowledge management in education: defining the landscape[END_REF]. However, KM practices in universities are often limited to the storage and dissemination of lecture slides and other relevant materials in virtual learning environments [START_REF] Leung | Enhancing learning experience of coursework students in higher education: a knowledge management methodology[END_REF]. Universities have not employed KM in its core business: education.

Politecnico di Torino has introduced KM to the issues related to automotive engine design. The course of Powertrain Components Design provides students with the necessary knowledge for the structural design, sizing and verification of main engine components by using analytical, semi-empirical and numerical approaches. These tasks allow students to perform calculations, but they might not have a graphical representation of their analysis. Modelling all the elements of the engine would become a time consuming task, focused on calculation rather than designing activities; further, students may lose the global picture of the designer activity.

Therefore, as first attempt, an instrument to generate a 3D parametric CAD model was developed; it provides the designer with a first simplified vision of the engine components [START_REF] Rosso | Integrated CAD/CAE Functional Design for Engine Components and Assembly[END_REF]. However, even if this solution was a promising method, it presented some drawbacks. As a matter of fact, the developed software was devoted to teaching purposes and lacked completely industrial practical knowledge.

In the next sections, this paper presents the tool and implementation in a university course.

Engine Paradigm

A paradigm is a set of assumptions, concepts, values, and practices that constitute a way of viewing reality for the community that shares them, especially in an intellectual discipline [START_REF] Kuhn | The Structure of Scientific Revolutions[END_REF]. Figure 1 shows the general paradigm process that has served as a framework for the study of the design practice in FCA. The model consists, firstly, in capturing knowledge by analysing previous projects. Next, it is necessary to formalize and store the common knowledge. Then, the final aim of the framework is to reuse the captured knowledge in new projects. However, in order to keep the knowledge at the state of the art, the model needs to be updated frequently. The paradigm approach has been applied to organize and capture the "technical skills" of people during the product development process of FCA, with the aim of increasing their average performance without blocking individual creativity. It is an infrastructure built and integrated into the CAD software Nx. It was developed by Vittorio Romagnoli (former FGA worker) and Domenico Giannetto (SIEMENS Industry Software -Italy). The development process of an engine was thoroughly studied, a group of 8 people (consisting in developers and expert designers) met one or two times per week over a period of 5 years. The study resulted in an infrastructure that allows to easily to conceive, validate and compare several combustion engine alternatives. The same principles were employed in the development of Die Paradigm (DP), which is currently being used by FCA. The main objectives of EP are twofold: first, to model directly the key components of an engine; second, to define and validate several product alternatives.

Modelling

The EP application is installed as an add-on of the CAD software and it requires a special license for its use. The EP assembly is made up of simplified components. The management of these components (insertion/removal in the assembly, control of their size and characteristics) is performed via defined User Interfaces (UI). At first, the components are created as copies (templates) of parts that exist in a library. Both the part library and UI can be easily modified and/or extended.

The main engine assembly consists of four functional groups (FG). Each FG is built by adding the parts that conforms the sub-assembly. Furthermore, each part is composed of smaller modules. In Figure 2 the FG crankshaft-conrod is presented. It is composed by four modules: counterweight (shown in orange), no counterweight, distribution terminal and flywheel. The modular strategy allows the system to easily respond to modifications. The actual configuration is a 4 cylinder engine and if the number of cylinders is extended or reduced the system automatically adds or eliminates modules. EP makes extensive use of parametric models that are computer representations of a design constructed with geometrical entities. Each entity has several attributes (properties): some of them are fixed (constraints); others can vary (parameters) [START_REF] Barrios-Hernandez | Thinking parametric design: introducing parametric Gaudi[END_REF]. The generation of a geometry defined by dimensions, parameters, attributes and rules keep the coherence of the design. This information is used, at a higher level, to propagate data between different layers of the assembly (interpart expressions) and to create associative copies of geometry between parts (wave links). EP consistently supports the parametric design of parts and assemblies: its structure allows keeping the design consistent with the constraints and thus increasing the designer ability to explore ideas by reducing the tedium of rework. The system allows creating the geometry of a complete engine from a scratch in a matter of minutes (a skilled user employs 15 min. while a new user requires 3 hours). Figure 3 shows a complete example of an engine developed with the support of EP.

Product Validation

Once the geometry has been created, the concept of the best engine configuration amongst several options must be validated. Starting from the preliminary product requirements, designers follow their train of thought, perform calculations and use technical languages to describe a potential solution. The design process is iterative and reaches the final solution after several loops, as part of the required data is not available at the beginning. At this stage the designer needs a project dashboard that monitors the current status of the product alternatives in terms of values and checks performed.

EP is able to control and maintain the consistency between several part-sketches belonging to different parts managed in the product study. Figure 4.a shows the main Engine data dashboard that contains all the information that can be modified at the main assembly level. Figure 4.b presents a particular frame of the Engine General Data. The designer can change the values of all the different parameters. Some of these inputs are not independent with each other; the unconstrained changes may lead to a condition where constraints are not respected. Hence, a set of checkers (green circle in the picture) have been implemented to help the designer to quickly evaluate if entered values are meaningful. Moreover, it is possible to fix the value of an important parameter (see the green lock of Figure 4.c) once it has been determined. In this case, the designer can continue to explore solutions with the certainty that this input cannot be changed.

The system also allows to quickly configure products alternatives while assuring compliance with international standards or industrial best practices. Figure 5.a shows two possible valve arrangements; the designer will choose the best solution according to the intake/exhaust location. Once the general schema has been defined, the distance between valves and between valves and engine head walls must be considered. This particular requirement is regulated by a FCA best practice. The system automatically calculates such distance (which is the result of the valve's angle) and shows a green flag (Figure 5.b) if the requirement is met. Finally, the 3D geometry is regenerated (Figure 5.c). Several meetings were necessary to agree the best strategy both from the technical point of view, with SIEMENS Industry Software -Italy, and from the property rights, with FCA. The complete updating of the tool took over three months.

After the successful EP upgrading, training on the use of the tool was necessary for all the stakeholders that participate to the project. The training consisted in two phases. The former included the complete development of an engine using EP. The overall behaviour of the structure was tested and several issues were identified and corrected. The latter consisted in the development of a custom example using the same structure. This was done to allow a better comprehension on the basic function of the tool. The tool was then installed and distributed in the laboratories.

Minimum material needed to resist 1 Automatic checkers based on norms

Deployment in a university course

The M.Sc. course of Powertrain Components Design is included in the 2 nd year of the automotive engineering curriculum in Politecnico di Torino. Approximately 40 students attend it each year. The course has a total duration of 100 hours. Approximately, 60 hours are used for theoretical aspects concerning engine and transmission design, while the remaining time is employed for laboratory activities. The laboratory practice is divided in the course's main topics: 20 hours for powertrain concepts and 20 hours for components design. EP is used in the latter section.

Students that attend this course come from different universities, different countries and different backgrounds (mechanical engineering, automotive engineering, production systems, etc.).

The goal of the practice is to design an engine while respecting the following constrains: i) 4 cylinder gasoline engine, ii) overall displacement around 1.2 litres and iii) power delivery 70 kW. Moreover, the development of the engine should take place as it is done in actual industrial practices, thus collaborative work is required. Students are requested to create a common engine; still each student faces different challenges and responsibilities. The group division and assignments are reported in table 1. The course chair defined the group division randomly. The only driving criterion was to avoid more than three people from the same country, in order to allow student's interaction and integration. Cylinder head Dimensioning and drawing, static analysis. Definition of the valvetrain and drivetrain system, valve spring definition 5

Manifold

Design of intake and exhaust manifold, computation of exhaust manifold 3

Results

At the end of the course, students presented their results. The evaluation of this presentation counts for a third of the final score. Additionally, direct student interview was performed to obtain feedback on the course. An interesting and useful discussion took place and pros and cons were highlighted.

Positive Aspects

Mainly, the course achieved its objectives satisfactorily and the contents of the course were considered original by the majority of students. The teaching method and material given were highly appreciated. EP allowed the students of the group to provide a complete assembly of the engine in less than 4 weeks. The main constraints, described in section 5 were respected. All the groups successfully developed the requested tasks on time. The obtained result is visible in Figure 6. EP allowed the students to reach a first design attempt of the overall engine in the established 20 hours of laboratory. On the contrary, the practice on powertrain concepts did not reach similar results, even if the same amount of time to this task were employed. This fact highlights the didactic relevance of EP.

In addition, students appreciated the easy and fast mounting of parts thanks to templates. The easiness of the UI was also greatly appreciated. Though, the most relevant aspect was the possibility to rapidly change all important engine parameters.

Future improvements

The laboratory infrastructure is only composed by 32-bits computers while the CAD system requires exclusively 64-bits machines. In order to by-pass this problem, a set of virtual machines were installed and distributed over the 32-bit machines. The infrastructure worked correctly but performed rather slow, especially when working with big assemblies.

One non-technological aspect that affected the development of the exercise is the previous knowledge on the CAD system. The M.Sc. course is attended by students that have heterogeneous education and not all of them were confident with the use

Engine fina l model -assembly

detail of crank mechanism detail of intake and exhaust manifold isometric view of the CAD tool. Such students tried to develop their parts in other systems and they found difficult the integration with EP.

Another issue that restrains the didactic objectives it the engine architecture: EP is limited to in-line engines because when it was created, there were no plans of developing other kinds of engines. Moreover, EP lacks of some important components such as the oil pan, intake and exhaust manifolds, valvetrain activation systems and oil pump. It is important to highlight that these components were designed by the students and they can be now imported to the EP library and to the UI. In addition, some sketches of the existing components must be changed in order to increase the geometrical control. For example, the counterweight opening angle should be included in the UI in order to quickly modify the counterweight mass.

The most important aspect regards the collaborative work. At this stage, EP works in a standalone version and it is not integrated to any Product Lifecyle Management (PLM) system. For this reason, each group worked independently and, after completing the study, communicated the final information to the project management team. This is a major issue that needs to be addressed immediately to assure a correct working method.

Conclusions

In this paper the introduction of an industrial Knowledge Management tool in a high level education institution was presented. This contribution extends the state of the art by showing evidence that the tool has been employed for didactic purposes and not only in staff applications. In fact, the use of Engine Paradigm in the course of Powertrain Components Design allowed students to take effective decisions while developing an engine. Students were exposed to the complexity of developing a product with the help of an actual industrial application. The tool facilitated the evaluation of several design alternatives while reducing the tedium of rework. The results obtained, compared to a similar exercise performed in the same course (same students), are really promising.

The experience gained in this first application has allowed authors to identify strengths, weaknesses and improvement opportunities. On one hand, positive aspects assures the goodness of the teaching strategies. On the other hand, the identified opportunities are now being studied. The proposed improvements comes from both students and professors. The embedded knowledge defined by its creators it is now being enriched with the actual requirements of the university.

Figure 1 .

 1 Figure 1. Paradigm approach

Figure 2 .

 2 Figure 2. User Interface and functional groups

Figure 3 .

 3 Figure 3. Engine Paradigm

Figure 4 Figure 5 .

 45 Figure 4. a) Main engine data. b) Engine general data overview c) Checker

Table 1 . 12 Crankcase

 112 Group subdivision for engine design practice Group Goals People Project management Definition of the engine layout and management of the group activities. 2 Piston Design of the piston, evaluation of piston slap, thermal analysis of the piston for defining the proper size, rings conformability 6 Piston Pin Design of the pin. Static and fatigue verification 2 Connecting rod Design of con-rod, considering bearing and screws 6 Crankshaft Flywheel, crank, check, crank pin and journal pin. Analytical analysis of torsional behaviour, potential mass damper usage, lubrication, drawing of the solution. Static and modal finite element verification. Definition of journal bearing. Definition of the geometry and of the construction philosophy, evaluation of water circuit, drawing and static verification. Liner dimensioning 5 Oil pan Drawing, modal analysis, optimization procedure 4

Figure 6 .

 6 Figure 6. Engine designed by the students


Jens Michael Hopf
email: michael.hopf@partner.kit.edu

Integration of Mobile Device Features in Product Data Management Systems

Keywords: PDM, Mobile Device Feature, Architecture, Product Development

Mobile devices have evolved rapidly in recent years and have become an everyday commodity. The young mobile PLM market is still in its infancy. At present, companies have covered their business processes with stationary workstations while mobile business applications have limited relevance and have been used to a limited extent. Companies can cover their overall business processes more time-efficiently and cost-effectively when they integrate mobile users in workflows. Mobile device features have the potential to significantly support the product development process through interactive user interactions and make them more effective. Moreover, entirely new workflows can be defined and established by considering mobile situations in business processes, which were excluded from the outset in the stationary context. This paper presents a novel approach for the usage of mobile device features in PDM systems to enhance user experience through novel interaction methods.

Introduction

The number of product variation on the world-wide market has increased significantly over the last few decades that consumers can easily find a broad range and assortment of goods [START_REF] Kinkel | Anforderungen an die Fertigungstechnik von morgen[END_REF], [START_REF] Holweg | The second century. Reconnecting customer and value chain through build-to-order: Moving beyond mass and lean production in the auto industry[END_REF]. Nowadays, customers have better access to information resources related to consumer products than 20 years ago. Detailed product features, competitive market exchange, and consumers who share their experiences with others are no longer obstacles. Compared to earlier years, this results have been changed in several significant ways. The consumer behavior has been less continuous and unstable than before. Consumer behavior has been changed in such a way that customers increasingly expect a product experience. It is equally important for the consumer to be able to identify with the product, because it is not only a product, but also offers valuable experiences. Through this shift, partly as a result of an improved market transparency, the power of the consumer has been expanded, so that companies must respond more to customer needs and thereby being found difficult to build a loyal consumer base who tends to switch faster the product and therefore the manufacturer. In order to ensure customer loyalty, on the one hand the company must have a high level of innovation capability to place new ground-breaking products and solutions with unique characteristics on the market and on the other hand it is essential to offer new products to the global market in even shorter intervals. A high pace of innovation and the constant shortening development cycles of products have become major challenges for companies and their employees. Whereas previously decisions were made only in the late phases of the product life cycle, this has been postponed due to cost savings, shorten the product development, and production in an earlier phase of the design and construction process [START_REF] Eigner | Product Lifecycle Management[END_REF]. Employees must be assisted by their company in their task to provide a permanent access to appropriate information over the entire product life cycle at the suitable time in the right place and in the appropriate form where they are needed [START_REF] Sendler | Das PLM-Kompendium. Referenzbuch des Produkt-Lebenszyklus-Managements[END_REF]. The quantity of information is not important, but rather a purposeful provision of information for the respective mobile context of the person to fulfill and support them in their tasks. However, this implies a deeper connection between the different stages of a product life cycle having a huge impact on other stages. To achieve this for PDM activities in mobile situations, totally new approaches for collaboration and interaction must be innovated and developed with the support of the all product lifecycle stages. An improved collaboration with the appropriate stages could be achieved if a better supply and contribution of information takes place. When a timely and up to date data supply is established quickly, the areas can start to plan more effectively the next steps, which shorten the follow-up process and the product quality. In this context, the importance of information quality in PLM must be taken into account and is discussed from a production process perspective [START_REF] Wuest | Product Lifecycle Management in the Era of Internet of Things[END_REF]. This paper presents a novel approach of mobile device feature (MDF) usage for PDM systems as well as identifies and discusses MDF pattern. Different integration approaches for MDFs are presented and discussed with related limitations. This paper is organized as follows: Section 2 analyzes and evaluates currently used MDF techniques within the PDM field. Sections 3 and 4 present the methodical approach considered for the MDF integration as well as differentiate the terms for this work. Section 5 identifies MDF pattern whereas Section 6 presents and discusses the integration approaches. Section 7 and 8 presents an industrial use case and discusses the limitations. Finally, in Section 9, conclusions and suggestions for further research are formulated.

Related Work

In the field of Knowledge Management, research about user's context and presentation of content in the mobile environment has been performed as determined in [START_REF] Antoniou | The Semantic Web: Research and Applications[END_REF] and [START_REF] Balfanz | A Reference Architecture for Mobile Knowledge Management[END_REF] as well as proposed knowledge framework in [START_REF] Zammit | A Framework to Capture and Share Knowledge Using Storytelling and Video Sharing in Global Product Development[END_REF]. Nevertheless, both approaches are limited to the semantic collaboration and content presentation. An approach for the integration of powerful hardware features in a generic way is still missing and is presented in this work. Methods focusing only on different types of mobile applications have their limitations. The implementation of business applications designed for various mobile operating systems is very time-consuming and expensive, thus it is difficult to develop such application as well as implement process changes in a short time interval. Today, those native business applications have to be individually designed and implemented for each mobile operating system and for each business process. Moreover, the diversity of platform specific user interfaces was examined in [START_REF] Larysz | User Interfaces and Usability Issues Form Mobile Applications[END_REF]. The usability across all platforms for operational purposes on the basis of native applications is difficult. In a business environment it is important to access company-specific functions and processes using a unified way. Different user interfaces would negatively affect the productivity of the mobile user when they change the device platform. This point of view is supported by a survey performed by Page in 2013 that users ask about apps more than they ask about the device specification [START_REF] Page | Use of Mobile Device Apps in Product Design[END_REF]. Another aspect is the delivery of native business applications, because it is unusual to distribute company specific and internal software through application distribution platforms such as Google Play or Apple's App Store which are primarily designed for end-consumers. PDM applications are generally made for a selected circle of people who participate in the product lifecycle.

Native business applications on mobile devices are characterized by a wide variety of platforms, and also by limitation of simultaneous updates on all mobile devices at the same time. Web applications would solve the problem of updating, because they are browser-based largely executed on the server side, but they provide only limited access to hardware features. So far, it can be hard to combine the respective advantages of native business apps and web apps together for PDM, i.e. to model and manage various business processes centrally and to create dynamically new business processes considering mobile features. The classic mobile support for employees can be realized especially in areas where value added related tasks need to be provided in an environment characterized by mobility [START_REF] Hess | Technische Möglichkeiten und Akzeptanz mobiler Anwendungen. Eine interdisziplinäre Betrachtung[END_REF]. In addition, opportunities exist to increase the capability and efficacy through the integration between physical objects in the real world and business information systems [START_REF] Hess | Technische Möglichkeiten und Akzeptanz mobiler Anwendungen. Eine interdisziplinäre Betrachtung[END_REF] to cover existing PLM workflows for mobile users. The overarching objective was already defined at a general and abstract level for the Internet of Things in order to provide additional information for the realities and to minimize information gaps [START_REF] Fleisch | Das Internet der Dinge[END_REF]. In the field of CMMS 1 , there are already approaches of a web-based communications between mobile devices and maintenance systems. Such approach is described in [START_REF] Campos | A web and mobile device architecture for mobile emaintenance[END_REF] as a multi-tier architecture, which is based on CMMS and DSS2 web services. This paper has simulated a corrupt bearing, which sensor data was read from the machine and stored for data acquisition as well as signal analysis in the database. Mobile users remotely access the results through the middleware layer. In this context, a bridge between the field of PLM and CMMS/SLM3 would be beneficial.

Methodical Approach

Firstly, it is essential to identify and delimit the different contexts of MDF usage and subsequently understand their interactions and relationships. The contexts Users, Software, and Business could be identified (see Figure 1). Mobile applications are dependent on the particular mobile platform, so that the development requires enormous efforts to ensure a consistent user experience across all mobile platforms. The variety of mobile platform and device types represent the wide spectrum of mobile technologies which satisfy different uses depending on the context and can be used at various locations. Finally, the Business context is dealing with different PDM providers with partly proprietary components. Traditional worker's desk of engineers participating in the lifecycle, has mainly a local workstation in the office. This workstation is used to handle all engineering tasks and decisions from a single point. Once an engineer leaves the workspace, a contribution of new information is no longer possible and all important product data are limited accessible if it has not been printed or noted. Therefore, product information can only be consumed unless it has been selected before. Any new generated information which is related to the lifecycle can only be transferred to the PDM backbone when the engineer returns to the workplace. Here, new knowledge could be lost when information has been only communicated verbally between the persons or written down on a piece of paper. In addition, new updates will be reported back to the lifecycle after a time delay. Other persons involved in the lifecycle could access the updated status only after a certain time. Incorrect product information can cause in such situations additional costs for the company and delays in the lifecycle. Such impacts could have a negative effect on the competitiveness of the company. In a study published by the Institute of Mechanical Engineering (ITM) at the Ruhr University Bochum in cooperation with IBM was identified as the primary potential benefits in the product lifecycle, the increase of the process efficiency through faster data distribution, data access, data search as well as less repeated re-entry of the same data [START_REF] Abramovici | Benefits of PLM in der Automobilindustrie[END_REF]. Such situations of missing or invalid product information can be avoided by mobile solutions and also improve the productivity of the business because new updates are immediately available for other persons involved in the product lifecycle.

Mobile Device Features

Currently there is not clear understanding what MDF stands for. MDFs represent capabilities and services of a mobile device in order to generate added value for the user. For example, using the smartphone camera to scan the barcode of a book to query additional information about author. Conventional mobile phones offer only basic functionalities like phone to each-other and save contacts on a SIM card, while feature phones provide advanced capabilities such as camera and web browser. However, feature phones do not provide the width range of capabilities as smartphones. Smartphones are considered as high-end devices because the higher purchase price compared to low-end feature phones warrant additional hardware feature and thus better hardware equipment. In addition, feature phones are mainly provided with a restricted manufacturer-specific proprietary firmware. However, smartphones provide a mobile platform with an extensive API that allows the provision of own mobile applications. In addition, the API integration to access hardware-specific features of the mobile platform is more efficient. Initially, a clear distinction and definition for the terms hardware feature, software feature and Mobile Feature are carried out. A hardware feature represents a hardware-specific technical capability which is not supplied by the mobile platform, but managed and controlled. For example, a camera consisting of a lens, image sensor and other components. A software feature is an ability that is completely provided by logical software-based components. This type of capability does not require hardware specific characteristics, such as a pocket calculator or a file manager. At work, a mobile feature is seen as an abstract element, which is derived and composed from hardwarespecific and software-based capabilities. However, it is not necessarily required for a mobile feature to be derived from both types of capability. Table 1 illustrates this aspect. The user story must be described in an adequate level of detail to derive the corresponding use cases, requirements, and finally to identify patterns. Subsequently, the patterns are described and assigned into various categories. From the variety of application scenarios, eight primary groups were derived and abstracted (see Figure 2). These abstracted application scenarios cover most of typical scenarios from the PDM domain and can contribute added value to the mobile PDM sector. The groups are composed mainly by activities (verbs) that express an action or a state of an object. Accordingly, objects can be observed, identified, analyzed, located, examined as well as objects can collaborate and information over objects can be contributed. However, the grouping can also be organized from the feature perspective and therefore a distinction into three groups takes place: (1) a feature interacts with the user independent from foreign components, (2) a feature works within a dependent component (e.g. workflow) as well as (3) a feature works independently and automatically from other components without user interactions. The classification by object activity appears to be more suitable.

Fig. 2. Groups of MDF pattern 6 Mobile Device Feature Integration Approach

The MDF integration can be accomplished by different options (see Figure 3). The first option describes the direct integration of mobile features in the PDM system. In this case, the mobile device features are called directly. The control and management of the mobile devices and associated features for all device classes takes place directly in the PDM system. However, this integration type is problematical in two respects.

On the one hand the core competence of the PDM is the provision of product development data across all product lifecycle phases and not the control and administration of MDFs for all mobile device classes, and on the other hand, rapid technological leaps in mobile ICT sector represent an enormous challenge for PDM manufacturers. The second option pursues the notion of an outsourced control and management competence into the mobile web application. This option prevents potential problems with configurations and customizations of the PDM system. However, the basic problem with this method is that all mobile web applications possess these competencies of MDF control and no overall coordination of various feature-enabled mobile web applications exist. Furthermore, additional expenses arise for the feature logic development and maintenance in the web application. The third option favored a framework for the integration of MDFs. The competences of the framework include administrative tasks of the feature control, assignment and provision the MDFs for various mobile web applications and PDM modules.

Fig. 3. PDM integration options for mobile device features 7 Industrial Use Case

This paper has applied the presented approach by a case study of developing a webbased mobile application to query the PDM data of an 'Issue' object and using MDFs to perform object-related tasks (see Figure 4). Based on the patterns, the mobile user can perform various object interactions such as View, Navigate, Capture, Localize, and Identify through the MDF support. Conventional input devices (e.g. soft keyboard of the mobile device) are no longer compulsory to interact with digital objects in the PDM world. All context-related interactions with the object are performed for the current user context. The interaction is not limited to a specific object types, but can be used for all objects in the PDM system and other software systems.

Limitations

The MDF usage in PLM provides not only benefits, but also have some limitations:

1 The technological progress requires a continuous reconsideration of MDFs. Serious changes can be observed particularly in the mobile sector, because new device classes are pushed in the market in short time intervals and new technological standards are being set. Mobile platforms are strongly affected because the support is completely discontinued after a few years. The missing technological adaptation of implemented software to new technologies would ultimately lead to unsupported configurations in newer software versions as well as incompatibilities may result in various infrastructure components. However, the business logic would not be affected, because the business logic is isolated from the mobile devices and operates independently. 2 The social interactions can take an influence on the social relationship of people.

The nature of the social interactions and its impact on the social relationship may have country or region-specific reasons. Thereby, social aspects addresses the privacy, user context, and cultural needs which plays another important role for the user acceptance of MDFs. The behavior of the mobile user is deeply rooted into the culture and linked to social aspects. Cultural aspects are often not sufficiently taken into account in mobile software. The perception of cultural backgrounds is complex, because the patterns differ in a high degree from culture to culture. Thereby, the privacy of every culture is more or less pronounced. Cultural aspects are comprehensive and diverse. Therefore, a more detailed and country-specific research that captures the relevant cultural aspects are required. 3 The MDF usage also places demands on mobile networks such as network reliability, system availability, standardization, costs for transport of mobile data, and communication encryption. Most of the developed country fulfill the demand but there is a gap particularly in rural regions and developing countries.

Conclusions and Future Works

This paper has presented an approach for the integration of MDFs in PDM systems to close the gap in the interaction of objects between the real objects and digital PDM objects. The suggested approach provides significant advantages for mobile users in the interaction with PDM information but also other software systems such as ERP and CMMS. For many years, PDM-related tasks have been performed exclusively on stationary workstations. By introducing new classes of mobile devices, the mobile revolution began ultimately, which led that long-established patterns of thought and behavior were broken and existing processes have been accordingly revised or completely redefined. Existing processes have been accordingly revised or completely redefined. This meant that mobile situations could be considered now and will not be excluded from the outset anymore. The mobile revolution has initiated a change that defines new standards in the communication and interaction between people in various industrial fields. MDFs are insufficiently used for industrial purposes. However, the market demands that companies of various industrial sectors increase steadily the innovativeness and the efficiency of processes and operations so that products in a wide variety can be pushed in the market in ever shorter development cycles. Companies that do not bow to the market conditions lose competitiveness and will quickly fall behind. In order to prevent this case, free space for creativity and innovation must be given to employees. Since most creative ideas and inspirations arise spontaneously and are first discussed by the employees in the collective, MDFs support the employee in the media communication and interaction in mobile situations. In addition, data is collected mainly through manual input forms that have not been optimized for mobile applications. Furthermore, user-specific contexts are neither perceived nor taken into account in the application. MDFs assist users in this situation in the data acquisition and consummation over all stages of the product lifecycle through innovative data interactions and context-sensitive information. The specific problem lies in a missing generic possibility to integrate features for PDM systems. The fact that the majority of mobile PDM applications have been implemented proprietary and natively, a unified and cross-system look ahead approach was missing to solve this problem. Therefore, it was necessary to develop an approach that takes into account the various aspects of the mobile feature integration from a generic perspective. Only such an innovative and holistic approach provides the possibility to integrate mobile features for all phases of the product lifecycle and to avoid isolated solutions in form of individual native implementation in context of mobile PDM applications.

Fig. 1 .

 1 Fig. 1. Contexts of mobile device featuresFirstly, the User context focus on mobile users who interact in a mobile context. This context can be divided into three sub-areas. The technical level describes the challenges of the user dealing with mobile devices. The main focus is set on the user who has developed a corresponding behavior due to the technical circumstances. The social level represents the acceptance of the mobile user to communicate because of the technical capabilities of a device. Finally, the personal needs of the mobile user are investigated on the human level in order to achieve a high user acceptance of the mobile device. Secondly, the context of Software has to deal with the technical integration part which has a wide range of mobile operating systems and MDFs. Mobile applications are dependent on the particular mobile platform, so that the development requires enormous efforts to ensure a consistent user experience across all mobile platforms. The variety of mobile platform and device types represent the wide spectrum of mobile technologies which satisfy different uses depending on the context and can be used at various locations. Finally, the Business context is dealing with different PDM providers with partly proprietary components. Traditional worker's desk of engineers participating in the lifecycle, has mainly a local workstation in the office. This workstation is used to handle all engineering tasks and decisions from a single point. Once an engineer leaves the workspace, a contribution of new information is no longer possible and all important product data are limited accessible if it has not been printed or noted. Therefore, product information can only be consumed unless it has been selected before. Any new generated information which is related to the lifecycle can only be transferred to the PDM backbone when the engineer returns to the workplace. Here, new knowledge could be lost when information has been only communicated verbally between the persons or written down on a piece of paper. In addition, new updates will be reported back to the lifecycle after a time delay. Other persons involved in the lifecycle could access the updated status only after a certain time. Incorrect product information can cause in such situations additional costs for the company and delays in the lifecycle. Such

Fig. 4 .

 4 Fig. 4. Interaction with PDM objects using acceleration sensor and voice recognition as MDFs

Table 1 .

 1 Mobile device feature examples.

	Example No. Mobile Feature	= Software Feature	+ Hardware Feature
	1	Object Identification = Object Recognition	+ Camera
	2	Person Localization	= Personal Identification + GPS
	3	Language Assistant	= Speech Recognition	+ Microphone
	4	Authenticator	= Fingerprint Recognition + Fingerprint sensor

PDM concepts cover a variety of application scenarios differing from the respective industry and individual customer requirements. Customers describe abstractly formulated user stories about what functions and features the software is supposed to provide.

Computerized Maintenance Management System (CMMS) describes the logical support of maintenance procedures for products and product-related components

Decision Support System (DSS) describes a software-based system for operational and strategic decision-making.

Service Lifecycle Management (SLM) deals with the lifecycle administration and control for product service activities