International journal of computer integrated manufacturing , tập 23, số 10, 2010

Implementation of product lifecycle management tools using enterprise integration engineering andaction-researchNicolas Pen˜arandaa, Ricardo Mejı´ab, David Romeroaand Arturo Molinaa*a Re

Implementation of product lifecycle management tools using enterprise integration engineering and

action-researchNicolas Pen˜arandaa, Ricardo Mejı´ab, David Romeroaand Arturo Molinaa*a

(Received 3 November 2009; final version received 18 May 2010)

This paper describes how enterprise integration engineering (EIE) and action-research (A-R) can be used to supportthe implementation of product lifecycle management (PLM) tools The EIE concept is used to align the corporatestrategies with the use of PLM technologies in order to impact the key performance indicators (KPIs) in theenterprise An EIE reference framework is proposed to define strategies, evaluate performance measures, design/re-design processes and establish the enabling tools and technologies to support the enterprise strategies, while A-R

is proposed to guide the PLM tools implementation at various stages of the product development process Anindustrial application is described to demonstrate the benefits of applying EIE, A-R and PLM in an enterprise

Keywords: enterprise integration; enterprise modelling; product lifecycle; action-research; industrial application

1 Introduction

Business managers are looking for new ways of improving

their company’s performance For this reason, concepts

such as enterprise integration (EI) and product lifecycle

management (PLM) have emerged to help companies to

be successful facing these challenges

EI is a domain of research developed since the

1990s as an extension of computer integrated

manu-facturing (CIM) EI research is mainly carried out

within two distinct research disciplines: enterprise

modelling and information technology The first

discipline refers to EI as a set of concepts and

approaches that allow the definition of a global

architecture for a system, the consistency of a

system-wide decision making, the notion of a process

which activity flow model goes beyond the borders of

functions and the dynamic allocation of resources as

well as the consistency of data (Vernadat 2002) In the

second discipline, information technology, EI is carried

out through the integration of several enterprise

systems, such as: Enterprise resource planning (ERP),

supply chain management (SCM), customer

relation-ship management (CRM), business process

manage-ment systems (BPMS) and also by authoring

functional applications such as: computer aided design

(CAD), computer aided manufacturing (CAM),

com-puter aided engineering (CAE), Office automation, etc

(Panetto and Molina 2008) All these systems and

applications support the implementation of processes

that sustain the enterprise operations

Enterprise integration engineering (EIE) is thecollection of modelling principles, methodologies andtools that support the integration of different enter-prise lifecycle entities (e.g enterprise, project, product,processes) The EIE foundation relies on the creation

of an enterprise model of the different entities in anenterprise, aiming at building a complete representa-tion of an enterprise that consists on the definition oftheir mission, strategies, key performance indicators(KPIs), processes and competencies and their relation-ships (Nof et al 2006) EIE allows a detaileddescription of all the key elements of an entity (e.g.activities, information/knowledge, organisational as-pects, human and technological resources) and severallanguages may be used (Cuenca et al 2006) In anenterprise model, this description provides the means

to connect and communicate all the functional areas of

an organisation to improve synergy within theenterprise, and to achieve its mission and vision in aneffective and efficient manner (Molina et al 2005).Furthermore, EIE enables an enterprise to share keyinformation/knowledge in order to achieve businessprocess coordination and cooperative decision-mak-ing, and therefore achieving enterprise integration.PLM is a strategic business approach that is used toachieve ‘enterprise integration’ for product develop-ment It has the intention to reduce inefficiencies acrossthe whole product lifecycle (Grieves 2006) The PLMconcept is focused on integration of lifecycle informa-tion and knowledge supported by computer aided

*Corresponding author Email: armolina@itesm.mx

Vol 23, No 10, October 2010, 853–875

ISSN 0951-192X print/ISSN 1362-3052 online

Ó 2010 Taylor & Francis

DOI: 10.1080/0951192X.2010.495136

engineering technologies such as: CAD, CAM, CAE,

and knowledge-based engineering systems (KBES)

PLM aims to support the management of the product

development process through the stages of its lifecycle,

from its conception to its recycling or disposal PLM is

recognised by the world’s leading universities, institutes,

and solution vendors as the next big wave in enterprise

software applications in the market and as a key

technology to support the new competitive strategy, value

chain strategy and production/service strategy in an

enterprise (Ming et al 2005) The emerging software

market is a suite of tools used to plan, manage and execute

lifecycle activities, which include identifying business

opportunities, prioritising R and D efforts, developing

new products, and supporting their production and

introduction to the market (Rozwell and Halpern 2004)

or even closing the lifecycle loop, as Jun et al (2007)

proposed by integrating new technologies to gather

real-time feedback

However, PLM systems might be considered also

an important concept for a complete Enterprise

Integration in an enterprise that aims to carry out

lifecycle engineering activities The work presented by

Jianjun et al (2008) describes an example of product

lifecycle engineering design based on a design for

excellence (DFX) approach and treating information

exchange issues in order to lead the engineering design

to an effective and efficient adoption of a sustainable

product development paradigm Gao et al (2003) at

Cranfield University has integrated product data

management (PDM) and PLM technologies, to

de-monstrate that PLM can improve enterprise’s ability to

effectively manage their supply chains and

collabora-tion around concurrent product developments between

separate offices and also with sub-contractors, enabling

enterprise integration

PLM integration and coordination in an enterprise

remain challenging because of its knowledge intensive

nature The study carried out by Siddiqui et al (2004)

investigates the problems and issues faced by

compa-nies when implementing PDM systems, which is one of

several components needed for a complete PLM

implementation A set of key factors, such as a lack

of management support, implementation issues, user

acceptance and costs, should be considered

Further-more, according to Bygstad et al (2008), the

turbu-lence of the business environment and the technical

environment complexity are the main challenges to

face Schilli and Dai (2006) emphasise the necessity of

a deeper understanding of a current business, the

design of appropriate processes and the

implementa-tion of a supporting IT architecture Garetti et al

(2005) propose a set of experimental learning

techni-ques and a change management approach in order to

reach a better PLM implementation, recognising the

central role of virtual simulation, business processanalysis techniques and process mapping, and remark-ing on the importance of adopting solutions that areflexible and adaptable owing to the constant changes inenterprises processes Another important component

of PLM systems is workflow management, which is anissue as illustrated by Rouibah et al (2007) Theenhancement of process design through the creation ofbuilding blocks as well as the enhancement oforganisational structure through the usage of roles as

a resource for process activities is a major achievementfor PLM definitions

For these reasons there is a strong need for asystematic, methodological and technology supportedapproach to develop and sustain a successful PLMimplementation in an enterprise, which is aligned toachieve a complete enterprise integration Action-research (A-R) is proposed in this paper as amethodology to support the implementation of PLMtechnologies in an enterprise

This paper describes how enterprise integrationengineering (EIE) - a framework and a methodologyfor enterprise integration – have been used to align thestrategic objectives of an enterprise to improve itsengineering processes using information technologies,

in particular in the implementation of PLM tools Theunderlying methodology used to support the PLMimplementation process is A-R in order to take asystematic approach of planning, implementing, ob-serving and evaluating the process By using A-R it ispossible to improve key performance indicators (KPIs)

in the enterprise and justify the implementation ofPLM technologies A case study in a real enterprise ispresented to demonstrate the usage of thismethodology

The paper has been organised as follows: Section 2describes how the EIE reference framework can beused to guide the PLM realisation project Section 3describes how A-R can be used to guide in three cycles

a PLM implementation Finally, a case study isdescribed in Section 4 to demonstrate the applicability

of EIE and A-R in PLM implementation projects

2 Enterprise integration engineering referenceframework

The EIE reference framework components are picted in Table 1 The EIE reference framework has itsfoundations on CIMOSA, ARIS, PERA, ZACHMANand GERAM reference models and frameworks EIEuses reference models and frameworks to supportstrategies development by applying three key concepts:(1) lifecycle principles, (2) enterprise models, and (3)instantiation in different domains (Chen and Vernadat2004) (see Figure 1) Each of the different components

de-provides guidelines, methodologies and tools to engineer

business process changes (Molina et al 2005) The

components are: (1) strategy and performance evaluation

systems, (2) reference models for enterprise modelling, (3)

decision-making and simulation models and (4)

knowl-edge/information technology

Strategy and performance evaluation systems: They

support the definition of three types of strategies in the

enterprise (Molina 2003), namely:

(1) Competitive strategy: It should be translated

into a set of decisions of how an organisation

can deliver value to the customer

(2) Value chain strategy: It is about making

decisions of how an enterprise will establish

an organisational model (external and internal)

that will exploit the different possibilities to

build an effective and efficient value chain

(3) Production/service strategy: It defines how the

enterprise will produce or deliver its products

and/or services

All these strategies are associated with performance

measures to evaluate the impact of the strategy

pursued in an organisation

Reference models for enterprise modelling: It supportsthe visualisation of enterprise knowledge, processesand associated performance measures in order toidentify areas of opportunity for improvements Itcomprises five groups of the main business processes todescribe a generic structure of an ideal intra- and inter-integrated extended enterprise:

(1) Strategic planning

(2) Product, process and manufacturing systemdevelopment

(3) Marketing, sales and service

(4) Order fulfilment and supply chainmanagement

Strategy and Performance

Evaluation Systems

strategy, value chain strategyand production/service strategy

time, costs, flexibilityand environment

and core processes

(IDEF0, UML)

AS-IS and TO-BE: functions,information, resources andorganisation

Decision-making and

Simulations Models

best business practices and

IT and its impact on KPIs

simulation models to evaluatedecision-making

use of best business practicesand IT implementation

Knowledge/Information

Technology

and knowledge models

functional, coordination,collaboration or knowledgemanagement

Systems (BPMS)

performance System dynamics simulation: The

ap-plied theory of system dynamics and dynamic systems

modelling method come primarily from the work of

Forrester (1980) The models are built based on

feedback loops of key performance measures,

cause-and-effect models, feedback influences and impacts or

effects Therefore enterprise models of behaviour have

been developed to demonstrate the effects and impacts

of best practices implementation on performance

measures (Molina and Medina 2003) Discrete event

simulation: Simulation is the most common method

used to evaluate (predict) performance The reason for

this is that a quite complex (and realistic) simulation

model can be constructed using actors, attributes,

events and statistics accumulation Business processes

simulation can be performed, for example, in order to

evaluate resource usage and to predict performancemeasures among others (e.g delivery time, costs,capacity usage, etc.) (Molina et al 2005)

Knowledge/information technology: PLM systems allowproduct data management and use of corporateintellectual capital (knowledge) PLM, BPMS andbusiness process intelligence (BPI) tools support theexecution and analysis of process using business and

IT perspectives BPMS allow process design, executionand tracking based on process engine technology.BPI analysis supports decision making for predictingand optimising processes Enterprise systems includeapplications such as: ERP, CRM and SCM Enterprisecontent management (ECM) integrates the manage-ment of structured, semi-structured, and unstructured

information, such as software code embedded in

content presentations, and metadata together in

solutions for content production, storage, publication,

and utilisation in organisations (Pa¨iva¨rinta and

Munkvold 2005) Therefore, the utilisation of PLM,

BPMS and ECM systems together with BPI analysis

capabilities permit to track the document lifecycle and

capture experiences in the process design executed

Also, allow companies to support business change

using a technology driven approach, and permit the

project visibility, knowing who, what and when has to

deliver each activity as well as the information and

knowledge sharing along all the product lifecycle The

final goal is to integrate all the applications in order to

achieve enterprise integration

The EIE reference framework can be applied to

different fields such as: business process management

(Li et al 2005), integrated product development (Chin

et al 2005), processes redesign/reengineering,

knowl-edge management and project management The

application presented in this paper, offers to scientific

and industrial communities a different consideration of

the design process as the integration of key business

processes and therefore, be treated with EIE

formalisms This consideration improves tions as, nowadays, companies have a certain level ofmaturity around enterprise systems such as ERP, SCM

implementa-or CRM, but PLM is a novel strategy that should beconsidered in the same way A novel methodology isthen proposed, and validated through a case study,based on A-R in order to follow a methodic approach

to implement PLM tools, enabling KPI definitions andprocess modelling in order to identify key activities,people, information and resources, needed to asuccessful implementation

3 Methodology for implementation of PLM based onEIE and A-R

The methodology proposed in the EIE referenceframework is based on Action-Research (A-R)(Baskerville and Wood-Harper 1996) A-R is defined

as a spiral process that allows action (changeand improvement) and research (understandingand knowledge) to be achieved at the same time(Baskerville and Pries-Hejeb 1999) A-R, which em-phasises collaboration between researchers and practi-tioners, has much potential for the Information

Systems field, because it represents a potentially useful

qualitative research method, and it supports the

practical problem solving, as well as the theoretical

knowledge generation (Avison et al 2001, Chiasson

et al 2008) In this methodology, an A-R cycle is

constituted by four phases:

(1) Plan

(2) Act

(3) Observe

(4) Reflect

For the PLM implementation in an integrated way,

three A-R cycles are proposed, which increase the

knowledge in the business model and suggest

improve-ments in the AS-IS process (see Figure 3)

By the accomplishment of the third A-R cycle, it

can be said that the PLM system is implemented

However, as EI is the integration of several enterprise

systems, the A-R cycles may continue, but oriented to

achieve a complete EI implementation by considering

other enterprise systems (e.g ERP, SCM, CRM) if

they are not implemented yet An improvement of the

PLM system may be carried out, if needed The

different cycles of this methodology are described inthe following sections

This methodology provides a progressive way toevaluate the existing processes; define KPIs; as well asdesign, develop, and implement an improved PLMprocess It provides practical benefits as it is suited toprojects of high industrial potential (consulting or-iented) to implement novel and complex technologies.For this kind of approach A-R has shown to be avaluable method to implement PLM systems withevolutionary knowledge and experiences throughreflective cycles It provides consistency across projectsenabling better planning, based on conclusions issuedfrom reflections phases without avoiding flexibility tomatch project complexity

3.1 First A-R cycle – enterprise strategy and AS-ISmodelling

In the first cycle the enterprise strategy has to beunderstood and clarified The objectives of this firstcycle are: (1) to describe enterprise strategy and itsKPIs, (2) to model the process AS-IS and, (3) tosuggest new improvements on the AS-IS model These

objectives are achieved using interviews with strategists

and process owners, which know the current strategy

of the enterprise and understand the product

develop-ment process in the enterprise The different stages of

this first cycle are described next

3.1.1 Plan

Define work team, responsibilities, activities and

resources A project plan is made, according to the

scope, resources and work team defined The

integration of a multidisciplinary team is suggested,

which could include strategic planners, process owners

and information technology analysts to incorporate a

diversity of perspectives during the AS-IS and TO-BE

models definition

Analyse the vision, mission and strategic objectives in the

enterprise This activity is a fundamental step to align

the product development process improvements with

the enterprise strategy External consultants may

improve process definition, because they act as

impartial actors and can perform an analysis

without influence of personal interests The strategic

objectives in the enterprise can be presented as KPI

related to quality, volume, time, costs, flexibility and

environment These indicators will lead to the

following benefits:

Economical: Profit, Sales, ROI

Productivity: value added per employee, value

added per invested capital

Strategic benefits: According to the competitive

strategies selected by the enterprise They can be:

operational excellence (e.g cycle time, process

cost, yield), customer focus (e.g customer

loy-alty, customer satisfaction), and product/process

innovation (e.g sales of new products, time for

developing new products, time for recovering

investment)

Define project scope, impacts and benefits for the

enterprise The PLM implementation impacts and

benefits must be defined, and it must have a clear

influence on KPIs (e.g costs reduction, time to market,

or improved capacity to develop products) The EIE

concept can guide the efforts of implementing the PLM

system pursuing Enterprise Integration

Analyse the business strategic elements and key

performances indicators (KPIs) To set the context

for the PLM system implementation, there is a need to

clarify the enterprise strategy (competitive strategy,

value chain strategy or production/service strategy)

After the enterprise strategy has been clarified, KPIs

are selected to monitor the impact on it Thecompetitive strategy aims to achieve competitiveadvantage by following at least one of these threepossible strategies: (a) operational excellence, (b)product leadership, or (c) customer focus Suchgeneric strategies are related to Porter’s (1990; 1996)proposal: Cost leadership (operational excellencestrategy), differentiation (product leadership strategy)and focus (customer focus) Once the enterprisecompetitive strategy is understood, it is possible totranslate it into a set of decisions about how theorganisation can deliver its value proposition to thecustomer Value chain strategy is about makingdecisions on how an enterprise will establish anorganisational model that will best exploit itspotentials and opportunities to build an effective andefficient value chain Different directions can beconsidered and adopted as a value chain strategy: (a)vertical integration, (b) strategic business units, (c)horizontal integration and (d) collaboration (vertical

or horizontal network) Finally, a production/servicestrategy is based on the following elements:

Product description: Defines criteria required for

an enterprise to qualify or to win an order in aspecific market

Customers and suppliers characterisation: fines customers’ expectations and requirementsimposed on suppliers

De- Process definition: Specifies performance sures required in the execution of the activities inthe process

mea-All these factors are defined by order-qualification andorder-winning criteria (Hill 1989) The criteria are:price, volume, quality, lead-time, delivery speed andreliability, flexibility, product innovation and design,and lifecycle status Based on all these performancemeasures the following production/service strategy can

be defined (Rehg and Kraebber 2005): make-to-stock(MTS), make-to-order (MTO), assemble-to-order(ATO) and engineer-to-order (ETO) New produc-tion/service strategies have been defined by Molina

et al (2007), which include configure-to-order (CTO)and build-to–order (BTO) The product/service strat-egy defines the criteria that must be satisfied by theenterprise in order to be able to compete in the selectedmarkets and industries

Identify the key business process with highest impact anddrivers of change PLM could support differentbusiness processes Some of them of particularinterest for authors are: co-design, co-engineeringand product development Some KPIs in PLMimplementations may be: time to market, cost

reductions, increase collaboration between

stakeholders, improved organisation efficiency, and

reduction of project execution time Other indicators

defined by IT analysts are: how long it takes for a

process to be executed, what resources were used to

execute that process (among others, Pen˜aranda et al

2006) It is important to define which process is

going to be analysed, including specific stages of the

whole business process in the enterprise The stages

selected must have high benefits and impacts in

selected KPIs

3.1.2 Act

Model process AS-IS.The AS-IS model represents how

the product lifecycle process (e.g product, process or

manufacturing system) is currently executed In order to

perform an efficient AS-IS analysis, the use of graphical

representations is suggested, which help to identify

duplicated information, parallel activities, and

information and material flows There are some

standard notations and languages recommended to

model business process The first recommended by

authors and possibly the most used Business Modeling

Language is ARIS (Scheer 2000) ARIS is the union of

methodologies (Kalnins 2004), where modelling with its

eEPC (extended event-process-chain) diagram and other

related diagrams is only a part, as it takes into account

different views of the business process There are some

other tools that will depend on the level of confidence and

expressibility needed, such as: IDEF0 (integrated

definition methods), UML (unified modelling language)

and BPMN (business process management notation)

Some authors give a set of parameters to select the most

suitable language as, for example, those from Bertoni and

Cugini (2008): Formality extent of the modelling

language, easiness of understanding, level of detail, goals

description and process simulation

As mentioned languages meet the authors’

require-ments, four domains must be represented to build the

AS-IS model for the identification of the current

enterprise state: process, information/knowledge,

or-ganisation and resources (Mejia et al 2004), (Molina

and Medina 2003)

Process domain:

It describes the activities of an integrated product

development identifying the information flow

through the product lifecycle, resources,

con-trols, inputs and outputs incorporated in each

activity The objective is to identify the

core-processes and activities of an enterprise

Information/knowledge domain:

This domain allows the detailed description of

data, information and knowledge required in an

integrated product development Their structuremust be considered, in order to define thestarting specifications for a product data model(PDM) This facilitates the understanding of howproduct and manufacturing information isstructured

Organisation domain:

The human resources identification and the waythey are organised are defined within theorganisational domain It must establish therelations among functional areas and depart-ments, as well as partners involved in asimultaneous engineering environment (e.g con-current engineering) The organisation structure

is important, in order to identify the key players

in engineering activities, not only for execution,but also for reviewing, supervising andmonitoring

Resource domain:

It identifies the different technologies and cations used for organisations’ processes opera-tion and management Table 3 describes sometechnologies that can be classified in functional,coordination, collaboration and informationmanagement (Mejia et al 2007)

appli-3.1.3 ObserveEvaluate AS-IS model.Build and use discrete event ordynamic system simulations to identify improvementareas in the AS-IS model Using these simulations

is possible to identify which specific activities in the

AS-IS process could be reformulated and also, which toolscould improve this process The indicators defined aremeasured to obtain the initial state of the model (AS-IS) before the TO-BE model implementation

3.1.4 ReflectAnalyse and propose improvements in AS-IS model.Decide what recommendations and improvements can

be made to the AS-IS model and propose KPIs for thenew model (TO-BE) Evaluate the implications ofchanging the process in the process, information,resources and organisation domains

3.2 Second A-R cycle - TO-BE model definition

In the second A-R cycle, the TO-BE model definition isproposed and analysed The core-process identified isimproved within the enterprise strategies Theseimprovements are achieved using tools as dynamicsystem simulations and logical models The differentstages of this second A-R cycle are described infollowing subsections:

3.2.1 Plan

Elaborate a modelling plan based on logic models.Logic

models are tools to design, plan and evaluate programs

to achieve organisational benefits Logical models are

defined in terms of benefits, impacts, effects, results

and activities of a specific project (Alter and Egan

1997, Molina et al 2000 The pursuit of the logical

model allows the identification of the performance

indicators that best fit to the enterprise strategy

Therefore it is possible to define KPIs for the TO-BE

model Different logic models of best manufacturing

practices have been defined in order to describe the

potential impact in an enterprise of a specific project

(Molina et al 2000)

In Table 4, different components of the logical

model have been mentioned of what must be defined in

a logic model

The next table (Table 5) describes all the activities,

results, effects, impacts and benefits of implementing a

PLM using an Action-Research methodology

3.2.2 Act

Design and model the TO-BE process.Modifications in

the TO-BE model are included for improving

process efficiency The TO-BE model reflects

the team’s improved process to be implemented in

the PLM system Also, this TO-BE model will be the

base to define the product development workflow in

the following stages As well as in the AS-IS model

definition, process modeling notations such as ARIS,IDEF0, UML and BPMN are recommended todescribe the TO-BE model Barros and Hofstede(2008) propose five principles that have to beconsidered when modelling the conceptual businessworkflows: (1) organisational embedding, (2) scenariovalidation, (3) service information hiding, (4), cognitivesufficiency, and (5) execution resilience According toArmistead and Machin (1997), there are tendenciesabout the role of processes in structuring organisationsand, in particular, the development of horizontalorganisations structured purely around processes Ingeneral, the organisations appeared to be taking a lessradical view Instead, they had developed matrix-basedorganisations between functions and processes, andtended to adjust their functional structure to align withtheir identified processes

3.2.3 ObserveEvaluate the TO-BE model The use of dynamicsystems and/or discrete simulation is considered atthis stage in order to determine impacts and benefits inthe TO-BE model This evaluation is based on theobjectives defined in the logic model

3.2.4 ReflectAnalyse the differences between AS-IS and TO-BEmodels and define specific projects.This activity intends

to identify the differences between the AS-IS and theTO-BE model It decides benefits and impacts in

Functional

Information/ knowledge

support specific

functions

To share and manageInformation andknowledge

To interact andcommunicate

To manage and control tasks

systems that support

Collaboration systems tofoster cooperationamong engineers

Coordination systems tosupport sequencing ofactivities and flows

Management (PLM)system

the current product development process Impact on

the organisation and project members are difficult to

measure and analyse, but it is recommended to get

them involved in the entire implementation project to

achieve a greater acceptation

Define the scope of the TO-BE model implementation.It

is necessary to define which will be the first stages in

the proposed process that are going to be implemented

in the third A-R cycle Therefore the implementation is

done by phases, which optimise resources (human and

technological) in the implementation cycle (the third

A-R cycle)

3.3 Third A-R cycle – TO-BE model implementation

In this third A-R cycle a set of tools are selected to

implement the TO-BE model proposed An essential

consideration for the TO-BE model implementation

is the interoperability between selected technologies

Important efforts are being done by research

communities on maturity models for interoperable

environments according to the stakeholders’ ments Therefore, it is essential to consider standardsfor the feasibility to introduce innovativetechnologiesfor interoperability, tending to achieve PLM objec-tives (Subrahmanian et al 2005)

require-The stages of this third A-R cycle are described asfollows:

3.3.1 PlanElaborate an implementation plan based on logicalmodels and the TO-BE model.In this activity benefits,impacts, effects, results and activities are defined in theimplementation project Also, tools/applications areselected to complement the TO-BE model Thisactivity is used to set-up the entire technologicalinfrastructure (applications and tools) and personaltraining The infrastructure must be aligned with theTO-BE model, and this infrastructure must not beselected before developing the TO-BE model This lastissue is essential to be successful in the PLMimplementation

Service

Supply ChainManagement

recoveringinvestment

3.3.2 Act

Execute changes in workflow process, organisation,

human and technological resources Based on the

TO-BE model, changes in mentioned resources are

executed These changes are carried out in the

technological infrastructure that was implemented in

the previous stage Garetti et al 2005 propose three

ways to implement these changes in the enterprise: (1)

The niche project and follow-up approach - this is the

selection of a niche area inside the enterprise to

implement and verify the results and benefits of the

implementation experiment in a comparatively short

time; (2) the overall and step-by-step approach - which

needs more time to careful planning of the project

within the full enterprise scale; and (3) mixed strategy

-where many project segments are organised, adopting

the niche mode

3.3.3 Observe

Perform accountability of changes, impacts and benefits

Measurable parameters and monitoring techniques

that allow business managers to coordinate, track

and control the product development process are

identified The workflow model has to be considered,

in order to have a guideline for associating all

measurable data These data include, for example,

the enterprise and suppliers resources involved in each

activity (human and technological), which are

important for cost estimations (important measurable

parameters) and also for workload analysis

Furthermore, assigned dates and time for each

partner are also included, in order to control delays

or precedence problems based on unfinished activities

Similarly, activities’ input and outputs should be

controlled, for managing information flow and

availability of further activities (Pen˜aranda et al 2006)

3.3.4 Reflect

Conclusions and improvements in workflow process,

organisations, human and technological resources.After

the environment is technologically integrated and

implemented, it has to be managed and the loop for

continuous process management is closed by the use of

monitoring techniques It provides external visibility

while product development is being executed The

process management tracks events and data from the

workflow execution and provides both real-time and

historical tracking of what occurs in the workflow

engine Finally, an improvement process is performed,

in order to analyse a possible new TO-BE model (the

current process in execution is now converted in the

AS-IS) and maybe new design ameliorations can be

proposed to improve the business process (Pen˜aranda

et al 2006) After this cycle, Enterprise Integration

implementation could be continued with the integration

of different business processes in the enterprise or theimprovement of the PLM system implemented

4 Case studyThe following case study was developed in a MexicanSME (small and medium enterprise) named IECOS(Integration Engineering and Construction Systems)

A key advantage of having access to this company wasthe company size as, for SMEs, access to informationand close contact with managerial levels facilitates thetask of understanding the AS-IS model The oppositecase can be experienced with OEMs (original equip-ment manufacturers) as the way to capture the AS-ISmodel is usually more difficult

4.1 First A-R cycle – AS-IS model understanding4.1.1 Plan

Define work team, responsibilities, activities andresources The multidisciplinary team in charge ofdeveloping this project was composed by: (1) PLMimplementation team and (2) product developmentprocess actors (based on A-R principles) The ‘PLMimplementation team’ was constituted by an IT analystand a product development process specialist, theirmain activity was to lead and advise the achievement

of the project Three main ‘product developmentprocess actors’ were identified: IECOS itself,manufacturing supplier and the customer

Analyse the vision, mission and strategic objectives in theenterprise The commitment of the enterprise wasconfirmed, as IECOS had an interest in strengtheningthe product development process For this reason atechnological area was created to generate andinnovate new products The current interest in theenterprise is to produce ‘medical devices’, as it offers agreat business opportunity

Define the project scope, impacts and benefits for theenterprise The project objective is to optimiseperformance in ‘engineering-to-order (ETO)’ businessprocesses (production/service strategy) which is based

on an architecture that naturally integrates customersand suppliers The project scope is focused on productdesign and manufacturing IECOS has been working

in collaborative environments to integrate suppliersand customers, and to achieve a complete EIE it isnecessary to implement a system that impacts on thefollowing issues of the product development: (a) time

to market reduction, (b) project managementimprovement, (c) project team integration

improvement, and (d) increasing product quality.These benefits can be reached with a structured andeffective PLM implementation.

Analyse the business strategic elements and KPIs Thebusiness strategic elements and the key performanceindicators impacted are clarified in Table 6:

Identify the key business process with highest impact anddrivers of change The core-process defined was theproduct development process, which starts fromcustomer’s requirement to product manufacturing Thisprocess implies a high collaboration between projectmembers For this reason, collaborative, coordinationand information management tools would be evaluatedand selected to support collaborative business processes.4.1.2 Act

Model the process AS-IS Interviews were carried out

by the PLM implementation team to the productdevelopment process owners and actors who describedtheir roles in the product development process.Activities from each partner (IECOS, customer andsupplier) are shown in Figure 4

4.1.3 ObserveEvaluate the AS-IS model After analysing the productdevelopment process by the BPMN model, someconclusions were obtained The AS-IS model has beenused by IECOS in several projects, but many problemswere discovered in the collaboration and documentmanagement between project members Information isdistributed by e-mail or fax; design and manufacture tasksare discussed in face-to-face meetings and sometimes viaphone calls Due to the lack of integration, the design isevaluated by the customer in the last stages of the designprocess This issue causes several iterations in the process(conceptualisation and advanced design sub-process).This causes process owners to have to repeat manyactivities, resulting on a lack of time for productimprovements

4.1.4 ReflectAnalyse and propose improvements in the AS-IS model

In the AS-IS model, some problems were identified,such as information sharing and all actors involvement

in each project’s decision Information can be storedand captured, however, there are difficulties inretrieving stored information Changes in the productdevelopment process, organisation, human andtechnological resources are necessary to improve thecurrent model Improvement of the customerrequirements capture, using QFD tools, can decrease

the customer interaction in the design process,

although the use of collaboration tools is necessary

to improve the interaction between IECOS and the

manufacturing supplier (Revelle et al 1998)

4.2 Second A-R cycle - TO-BE model definition

4.2.1 Plan

Elaborate a modelling plan based on logic models.Table

7 summarises the logical model developed It describes

the benefits, impacts, effects, results, activities and

problems/necessities in the TO-BE definition The final

objective of this TO-BE model is to improve

collaboration, document management and coordination

within the project team along the entire product lifecycle

4.2.2 Act

Design and model the TO-BE process The product

development process has been re-configured to allow

customer monitoring along the entire process (seeFigure 5) Also, supplier can interact and participate inthe design process developed by IECOS, achieving

a design that minimises potential problems in themanufacturing and assembly stages A unique productdata management is used to store, capture and retrieveall product information generated by the project team.Using this proposed model, a workflow can bedeveloped to automate the process, and the teamcoordination can be improved

Some changes in the organisation, process, mation and resources are necessary to achieve thisbusiness opportunity:

infor- Organisation domaininfor- A new organisationalstructure has to be developed, including theproduct development area Customer and sup-pliers have to actively participate in designdecisions, improving customer satisfaction andmanufacturing quality and cost

members in the product lifecycle

customers and suppliers

constantly new products (ETO strategy is related toproducts that are manufactured to meet specificcustomer’s needs, requiring unique engineeringdesign or significant customisation Maincharacteristics in this model are: high customisation,long delivery time, no inventory level, high productcomplexity, and the source of competition is based

on differentiation and no repetitiveness (Amaro andHendry 1999)

Functional domain Product development process

has to be extended to manufacturing

develop-ment Some activities were added to involve

suppliers and customers in the design phases

Information domain IECOS presents a product

information model This model is structured in

components, which are associated with product

functions Link the Manufacturing model with

the product model, using bill of materials andmanufacturing specifications were developed

4.2.3 ObserveEvaluate the TO-BE model The improvements in theTO-BE model are focused on the implementation ofthe coordination, collaboration and information/knowledge management tools, which reduce theproduct’s time to market and improve the quality.4.2.4 Reflect

Analyse the differences between AS-IS and TO-BEmodels and define specific projects.The main differencebetween AS-IS and TO-BE models is the possibility tointegrate all project members in each design decision.The information is stored and can be retrieved forfuture projects (achieving Knowledge Management).Under this approach, project evolution can beconsulted by using workflows, capturing theknowledge generated in each project phase

Define the scope of the TO-BE implementation Thisimplementation is going to be focused on productdevelopment process in IECOS, from productconceptualisation to product manufacturing For thisreason, it is required to involve the customer andmanufacturing supplier in this implementation

4.3 Third A-R cycle – TO-BE model implementation4.3.1 Plan

Elaborate an implementation plan based on logical modelsand the TO-BE model proposed Improvements in theTO-BE model are focused on the implementation ofcoordination, collaboration and information/knowledge management tools They contribute toreduce the time to market and improve the product

Logic model

development process oriented toproduct development time reduction

activities, increasing value added byemployee, improve project teamintegration

correction

oriented engineering projects

knowledge in the TO-BE modeldefined

structure by involving customer andsuppliers in the product developmentdecisions

(organisation, resources and processimprovements)

organisation, resources and process

improvements

TO-BE model analysed

definition

quality An integration of functional tools is proposed

to achieve coordination between different actors,

which have different tools to develop their activities

This integration is reached by using document imaging

and CAD viewers to integrate the content of these

functional tools The logical model developed in this

A-R cycle identifies benefits, impacts, effects, results,

activities and problems/necessities (see Table 8)

4.3.2 Act

Execute changes in workflow process, organisation,

human and technological resources In this stage,

proposed TO-BE model is implemented and changes

in the workflow process, organisation, human and

technological resources are described as follows:

Workflow process: The product development process

was built in the workflow execution system of

SmarTeam (Dassault Syste`mes) platform (see Figure

6), based on the proposed TO-BE model This

work-flow allows information traceability and an overall

view of the design process Each activity contains a set

of tasks, and it is linked to a specific user, who becomes

responsible for tasks accomplishment Documents,

such as QFD results, can be attached to any activity

of the workflow, enhancing decision making according

to product specifications throughout the entire product

design process

Organisation resources: IECOS organisation has been

modified to support a horizontal integration in the

product development process, and a set of specific

activities were identified for each project member

Marketing, manufacturing (supplier) and design

de-partment were integrated in one product development

process, and each one has specific responsibilities over

the final product, not only in their particular areas

Human resources: The main activity was the training

and support in the PLM system The training was

given to suppliers, customers and product design team

Convincing them that using PLM tools can improve

the collaboration and the information management

process is an important task for the success of this

implementation

Technological resources: In this case study, SmarTeam

and QuickPlace/SameTime were implemented as PLM

technological platform SmarTeam offers an

informa-tion/data management (see Figure 7), which is

supported by logical links between product data,

metadata creation and tree structure data Also,

SmarTeam offers a web module, which allows the

information integration inter/intra enterprise and a

viewer module that allows information sharing tween the project team, without special applications tovisualise some documents (e.g CAD files)

be-QuickPlace (IBM application) is used as thecollaboration platform It is a workspace on the Webfor team collaboration among customers, suppliersand Business Partners QuickPlace provides access toinformation and documents at any time whether teammembers are co-located or geographically dispersed Inthis platform, additional documents related to projectmanagement (e.g project members, due dates, instruc-tions or tutorials) or documents related to documentmanagement (as version control) may not be needed

Logic Model

market faster, reducing costs

value per employee and per investedcapital

time for developing newproducts

process cycle time and cost,Gather and transfer knowledgerelated to product design

(project time)

corrections (hence less iterations)

incidence of product defects)

development, based on TO-BEmodel definition

(data and applicationintegration)

information management tools,collaboration and coordinationtools)

organisation, human andtechnological resources

systems (cultural change)

Problem/

Necessity

new technology and concept)

(Figure 8) Also, QuickPlace can interact with

Same-Time, which provides chat, videoconferences,

white-board and applications sharing in order to enhance

collaboration

The complete component architecture is described

in Figure 9, which requires the following IT

infrastructure:

E-HUB1 Server: Support the License Use

Management and the QuickPlace

E-HUB2 Server: Support the SmarTeam Data

Base and the SameTime

IBM-ST Server: Support the SmarTeamFoundation, Vault Server and SmarTeamEditor

CAX Server: Support SmarTeam WEB Editorand SmarTeam editor

Controller

This architecture is the minimum infrastructure needed toobtain an optimal performance Also, this architectureserves for ERP, SCM and/or CRM systems to achieve acomplete EI In the case study treated in this paper, the

Figure 8 QuickPlace and sametime collaborative tools.

product development and supply management was

included, achieving integration between the suppliers

and customers by using Web applications (QuickPlace/

SameTime and Web module of SmarTeam)

Finally, the product manufacturing was achieved

by being totally carried out through the implemented

PLM system (see Figure 10) However, the interaction

between suppliers and designers was not supported this

time by the collaboration tools implemented

4.3.3 Observe

Perform accountability of changes, impacts and benefits

In this implementation the information/data

management was improved, but it was difficult to

completely integrate the suppliers and the customers

The workflow and the document management were

only used by the design team (IECOS) to develop the

product design Using the PLM system, problems such

as version control, document search and retrieval, and

project coordination were solved Some indicators

considered were:

Reduced time execution for the product

develop-ment time (the entire project):This reduction is

because the improvement of the document

management and also, the number of design

iterations were reduced

Improvement of the Integration level (suppliers,

designers, and customer): The integration was

not fully accomplished, but the customer was

able to check and comment on the design of his

product while it was being developed The

supplier had some problems for the integration,

and he only participated in the last stages of the

process design

4.3.4 Reflect

Conclusions and improvements in workflow process,

organisations, human and technological resources.PLM

implementation improved the information

management, team organisation and integration in the

product design stages The difficulty to completely

integrate the customer and the supplier has revealed

that the main problem is not the technological

implementation, but the difficulty to carry out the

cultural change within project members Improvements

in the time execution and project management were

the key factors to achieve a successful implementation

4.4 Reference model and methodology results

In the case study presented throughout this paper, a

successful PLM system implementation was carried

out However, other changes, such as process,human and organisational improvements, had greatresults on the enterprise These results can besummarised in:

An improvement in the project management:Changes in the process design and application ofworkflow systems showed a clear definition ofeach activity that has to be developed In thiscase, each activity contains multiple tasks andwas linked with standards formats to be filled byeach person responsible The use of a workflowsystem (supported by Smart Team), enablesprocess automation, enabling the product devel-opment manager to know exactly the projectstatus With this system, the product develop-ment manager can be informed of responsibil-ities, problematic activities or deadlines

Integration of suppliers and customers: Keystakeholders were integrated during the designprocess Consequently, changes in the orga-nisation (roles definition) and process werecarried out These changes were supportedwith collaboration tools that enabled thisintegration

Better document management Informationsearch and retrieval is an important aspect toreduce Time-to-Market Finding where theinformation is produces a high spend of time aswell as rework time spend The use of productdata management systems is an importantsolution which centralises all the information in

a common database This system presentsmetadata searchers and the possibility to link-related data These characteristics enable tosearch and retrieve information without askingother team members, improving efficiency andreducing product development time

imple-mented PLM system

5 Conclusions

A PLM implementation methodology based on EIE

and an A-R approach was described in this paper, as

well as the results of its application in an industrial case

study The use of EIE reference model was an important

aspect to propose a holistic reference model that can

include key concepts such as enterprise modelling,

enterprise strategy and technologies integration

Con-sequently, these concepts were included by authors to

obtain a systematic methodology Nevertheless, that

was not enough It was necessary to include the A-R

concept as it is a practical and easy to use research

method that gives to the methodology the possibility to

be evaluated in each cycle and consequently to be

improved Moreover, A-R gives the possibility to reflect

in each end of cycle and make decisions on whether to

follow to the next cycle or not

PLM systems are a market differentiated and

value-added customer solution that can be used to decrease

project time and enhance product development process

in a company The proposed methodology is a

systematic approach that offers a set of tools to achieve

inter/intra-enterprise integration, enabling customer

and suppliers to actively participate and monitor the

product development process During the case study,

some important factors for the implementation of these

tools in the enterprise were identified, such as:

The cultural change It is very difficult to change

the way that some people are used to work The

main barriers to the success of PLM

implemen-tation may be: weak project management

leader-ship, weak participation and commitment of

team members (particularly the core team) and a

lack of integration with geographically

distrib-uted partners

PLM tools learning curve It is important to

consider the time spent on training and learning

how to use these tools Generally, these tools are

very specialised, and new vocabulary appears in

the day to day work (e.g check in, check out,

release documents, etc.) For this reason the

training process must to be a key activity in

PLM implementation process Suppliers and

customers need training as well and continuous

support in the first stages of the implementation

Further research As the PLM strategy is getting more

and more acceptance in the industrial sector of

developing countries, authors of this paper will

continue to research around PLM implementations on

Latin-American industries and all related methods and

tools to facilitate their implementations and its approach

to achieve full enterprise integration Future work

includes the extension of the EIE Reference

Framework toolkit for supporting the implementation

of different engineering tools, such as the PLM systems

as presented in this paper After this experience, somelimitations of the methodology may be stated as futurework For example, no ‘change management’ strategieswere tackled as, during implementation, the culturalchange made difficult to achieve some tasks as they wereplanned As it has been seen, usually PLM end-users areinitially reluctant until they really see the day-to-dayadvantages on their own activities improvements A stage

to raise awareness, after third A-R cycle, may be ofinterest to research and industrial communities Thisopportunity enables researchers and practitioners tothink on strategies to implement PLM systems, but also

to consider Post-implementation processes There is alsoanother opportunity on monitoring current projectsdeveloped under implemented PLM in order to collectsome data and further experiences

AcknowledgementsThe research presented in this document is a contribution forthe ‘Rapid Product Realisation for Developing MarketsUsing Emerging Technologies’ Research Chair, ITESM,

In-novation’ and ‘Design of Mechatronics Products’ ResearchChairs, ITESM, Campus Ciudad de Me´xico (Mexico)and the ‘PLM tools implementation process for engineeringprojects’ Research chair, EAFIT University (Colombia)

ReferencesAlter, C and Egan, M., 1997 Logic modelling: a tool forteaching critical thinking practice evaluation Journal ofSocial Work Education, 33 (1), 85–103

Amaro, G and Hendry, L.B., 1999 Competitive advantage,customization and a new taxonomy for non make tostock companies International Journal of Operations andProduction Management, 19, 349–371

Armistead, C and Machin, S., 1997 Implications of businessprocess management for operations management Inter-national Journal of Operations and Production Manage-ment, 17, 886–898

Avison, D., Baskerville, R., and Myers, M., 2001 ling action research projects Information Technology andPeople, 4, 28–45

Control-Barros, A.P and Hofstede, A.H.M., 2008 Towards theconstruction of workflow-suitable conceptual modelingtechniques Information Systems Journal, 8, 313–337.Baskerville, R and Wood-Harper, A.T., 1996 A criticalperspective on action research as a method for informa-tion systems research, Journal of Information Technology,11(3), 235–246

Bertoni, M and Cugini, U., 2008 Representing and sharingprocess knowledge in PLM systems design In: Proceed-ings of the 5th International Conference on ProductLifecycle Management, Seoul, Korea

Bygstad, B., Nielsen, P.A., and Munkvold, B.E., 2008 Fourintegration patterns: a socio-technical approach tointegration in IS development projects InformationSystems Journal Online early articles, DOI:10.1111/j.1365-2575.2007.00280.x

Chen, D and Vernadat, F., 2004 Standards on enterprise

integration and engineering – a state of the art

International Journal of Computer Integrated

Manufac-turing, 17, 235–253

Chiasson, M., Germonprez, M., and Mathiassen, L., 2008

Pluralist action research: a review of the information

systems literature Information Systems Journal

Online early articles, DOI: 10.1111/j.1365-2575.2008

00297.x

Chin, K.S., Lam, J., Chan, J.SF., Poon, K., and Yang, J., 2005

A CIMOSA presentation of an integrated product design

review framework International Journal of Computer

Integrated Manufacturing, 1362–3052, 18 (4), 260–278

Cuenca, L., Ortiz, A., and Vernadat, F., 2006 From UML or

DFD models to CIMOSA partial models and enterprise

components International Journal of Computer

Inte-grated Manufacturing, 19 (3), 248–263

Forrester, J., 1980 Principles of systems: text and workbook

Cambridge, Mass: MIT

Gao, J.X., Aziz, H., Maropoulos, P.G., and Cheung, W.M.,

2003 Application of Product data management

technol-ogies for enterprise integration International Journal of

Computer Integrated Manufacturing, 16, 491–500

Garetti, M., Terzi, S., Bertacci, N., and Brianza, M., 2005

Organizational change and knowledge management in

PLM implementation International Journal of Product

Lifecycle Management, 1, 43–51

Grieves, M., 2006 Product lifecycle management: Driving

next generation of the lean thinking New York, USA:

McGraw Hill

Hill, T., 1989 In: R.D Irwin and I.L Homewood, eds

Manufacturing Strategy, Homewood Washington DC:

Georgetown University Press

Jianjun, Y., Baiyang, J., Yifeng, G., Jinxiang, D., and

Chenggang, L., 2008 Research on evaluation

methodol-ogies of product life cycle engineering design (LCED)

and development of its tools International Journal of

Computer Integrated Manufacturing, 21 (8), 923–942

Jun, H.B., Shin, J.H., Kiritsis, D., and Xirouchakis, P., 2007

System architecture for closed-loop PLM International

Journal of Computer Integrated Manufacturing, 20 (7),

684–698

Kalnins, A., 2004 Business modelling Languages and tools

Mathematics in Industry, 4, 41–52

Li, H., Fan, Y., Dunne, C., and Pedrazzoli, P., 2005

Integration of business processes in Web-based

colla-borative product development International Journal of

Computer Integrated Manufacturing, 18 (6), 452–462

Mejı´a, R., Aca, J., Ahuett, H., and Molina, A., 2004

Collaborative e-Engineering environments to support

integrated product development In: L.M

Camarinha-Matos, ed Emerging solutions for future manufacturing

systems Austria, IFIP: Springer, 271–278

Mejia, R., Lopez, A., and Molina, A., 2007 Experiences in

developing collaborative engineering environments: An

action research approach Computers in Industry, 58 (4),

329–346

Ming, X.G., Yan, J.Q., Lu, W.F., and Ma, D.Z., 2005

Technology solutions for collaborative product

lifecycle management – status review and future trend

Concurrent Engineering: Research and Applications, 13,

311–318

Molina, A., 2003 Developing the enterprise concept – the

business plan In: P Bernus, L Nemes, and G Schmidt,

eds Handbook on enterprise architecture Berlin:

Spring-er, 333–369

Molina, A., Flores, M., and Caballero, D.M., 2000 Enquetesur les indicateurs de productivite et les meilleuresmethodes de l´industrie manufacturiere de Monterrey(Mexique) a travers une etude de Benchmarking.Revue Francaise de Gestion Industrielle, 19, 63–75, inFrench

Molina, A., Garza, J., and Jime´nez, G., 2005 Enterpriseintegration engineering as an enabler for business processmanagement In: P Bernus, M Fox, and J.B.M.Goossenaerts, eds Knowledge sharing in the integratedenterprise Springer/Kluwer, 269–278

Molina, A and Medina, V., 2003 Application ofenterprise models and simulation Tools for the eva-luation of the impact of best manufacturing practicesimplementation Annual Reviews in Control, 27, 221–228

Molina, A., Velandia, M., and Galeano, N., 2007 Virtualenterprise brokerage: A structure driven strategy toachieve build to order supply chains InternationalJournal of Production Research, 45, 3853–3880 DOI:10.1080/00207540600818161

Nof, S.Y., Morel, G., Monostori, L., Molina, A., and Filip,F., 2006 From plant and logistics control to multi-enterprise collaboration: Milestone report of theManufacturing and Logistics Systems CoordinatingCommittee Annual Reviews of Control, 30, 55–68.Panetto, H and Molina, A., 2008 Enterprise integration andinteroperability in manufacturing systems: Trends andissues Computers in Industry, 59 (7), 641–646

Pa¨iva¨rinta, T and Munkvold, B.E., 2005 Enterprise contentmanagement: An Integrated Perspective on InformationManagement In: Proceedings of the 38th Annual HawaiiInternational Conference on Systems Sciences, 95–96.DOI: 10.1109/HICSS.2005.244

Pen˜aranda, N., Aca, J., and Molina, A., 2005 Methodologyfor modular industrial plant development using ALMtools: An action research approach In: X Fischer and D.Coutelier, eds Research in interactive design 117 CDProceedings of Virtual Concept

Pen˜aranda, N., Galeano, N., Romero, D., Mejı´a, R., andMolina, A., 2006 Process improvement in a virtualorganization focused on product development usingcollaborative environments In: S Llanes and H.E.Heinz, eds 12th IFAC Symposium on INCOM, 611–

Rouibah, K., Rouibah, S., and Van Der Aalst, W.M.P.,

2007 Combining workflow and PDM based on theworkflow management coalition and STEP standards:the case of axalant International Journal of ComputerIntegrated Manufacturing, 20 (8), 811–827

Rozwell, C and Halpern, M., 2004 Product lifecyclemanagement for life science firms Gartner ResearchNote, TU-22-1634

Scheer, A.-W., 2000 ARIS business process modeling 3rdedn Berlin Heidelberg New York: Springer

Schilli, B and Dai, F., 2006 Collaborative lifecycle ment between suppliers and OEM Computer in Industry,

manage-57, 725–731

Siddiqui, Q.A., Burns, N.D., and Backhouse, C.J., 2004.

Implementing product data management the first time

International Journal of Computer Integrated

Manufac-turing, 17 (6), 520–533

Subrahmanian, S., Rachuri, S., Fenves, S., Foufou, S., and

Sriram, R., 2005 Product lifecycle management support:

a challenge in supporting product design and

manufac-turing in a networked economy International Journal of

Product Lifecycle Management, 1, 4–25

Vernadat, F.B., 2002 Enterprise modelling and integration(EMI): Current status and research perspectives AnnualReviews in Control, 26, 15–25

A web-based collaborative design architecture for developing immersive VR driving platform

Janus S Liang*

Department of Vehicle Engineering, Yung-Ta Institute of Technology and Commerce Linlo, Ping Tung, Taiwan 909

(Received 27 December 2009; final version received 13 April 2010)

In this study, based on the analysis of the dynamic nature of collaborative design process, a new framework ofcollaborative design for modelling an immersive VR automotive driving learning (imseADL) platform is described.This framework adopts an agent-based approach and relocates designers, system and the supporting agents in aunified knowledge representation scheme for imseADL design This study presents the research issues and industrialrequirements for such a system Furthermore, a prototype system of the proposed framework is implemented and itsfeasibility is evaluated using a real design scenario whose objective is designing an imseADL

In this system, each virtual element or assembly is designed as an independent unit The unit agent method is used

as the basic system modules To manage these unit agents, a web-based interface manager is provided The sceneexplorer is a virtual element design space based on unit agents and the interface manager To manage thecollaborative session, a web-based design phase manager is proposed In this situation, designers do not possess allthe knowledge they need but instead rely on other organisations In addition, this proposed system is an effective andvaluable architecture for collaboration design in today’s product development environment

Keywords: collaborative design environment; agent-based approach; knowledge engineering

1 Introduction

Product design, whether hardware or software in the

any field, is a team effort in which groups of experts

from many disciplines work together Close

coopera-tion among them will accelerate the product

develop-ment by shortening the developdevelop-ment cycle, improving

the product quality and reducing the investment

(Prasad 1996) Meanwhile, product design is a

knowl-edge discovery process, in which the information and

knowledge of diverse source are shared and processed

simultaneously by a team of designers involved in the

life phases of a product (Tang 1997) Hence, a

fundamental change is in need in the way in which

framework is developed in order to provide more

effective and efficient support to design collaboration,

upon which many product innovation strategies

depend

Among the existent technologies to support

colla-borative product development, the focus has been in

sharing product data and providing collaborative tools

to bring the multidisciplinary team together However,

there is still the need to capture and share the

know-how of the geographically distributed partners The

knowledge involved in this study is related to the

technological constraints that affect the decisions taken

when developing a product For example, driving site

planning and resources constraints that have to beconsidered for the development of an immersive VRautomotive driving learning (imseADL)

In previous work, the author (Liang 2009) offeredreferences for others who want to create a course thatfocuses on designing and generating VR systems.Meanwhile, this study concluded with a suggestedcourse framework that integrates the main componentsbased on experiences of instructing related courses.However, this study describes the development offramework that adopts an agent-based approach andrelocates designers, system and the supporting agents in

a unified knowledge representation scheme for seADL design In this study the system design,architecture, configuration and characteristics thatdifferentiate the previous system were presented Theadvantages of the presented approach and severaldisadvantages that have not been well solved but can

im-be effectively dealt with by the solutions proposed in thisresearch are described in the following sections.This study presents our approach and implementa-tion In the following sections, Section 2 gives anoverview the work related to this field Section 3describes the methodological approach and technolo-gical requirements for web-based collaborative designsystem in this study Section 4 presents the unit agents

*Email: janus@mail.ytit.edu.tw

Vol 23, No 10, October 2010, 876–892

ISSN 0951-192X print/ISSN 1362-3052 online

Ó 2010 Taylor & Francis

DOI: 10.1080/0951192X.2010.490276

based open CAD architecture Section 5 discusses the

communication and coordination methods of the

system The implementation is presented using a case

study of an imseADL, finally, in the last section

2 Related work

In the fields of computer-aided collaborative design,

the complexity in system architecture and information

structure is one of the main problem facing

research-ers The requirements for design coordination mixed

with differences among heterogeneous system

archi-tectures and information structures As a result, many

different data structures and communication standards

for collaborative design emerged While the cognitive

process of design collaboration is not well understood,

the computational tools and systems are being

devel-oped at an increasingly fast speed

Many researchers have done a great deal of work in

collaborative CAD systems Their research is generally

concerned with three aspects: product modelling,

consistency maintenance and system architecture

Product modelling is concerned with the model

contents and representation means for supporting the

model data producing and sharing (Shen and Barthes

1995, Dias 1996, ISO/STEP 1996, Rosenman and Gero

1996, Rosenman and Wang 1999) So far, most of the

papers in this field fall into the following several

portions:

(1) The development of a neutral product data

model that aims at facilitating product data

exchange between different CAX systems The

typical one in this portion is the STEP standard

(ISO/STEP 1996, ISO 10303 1994, ISO’s

official website 2009) created by the ISO

Most of the product data models in this portion

are generated based on the STEP and try to

better represent the design object with richer

semantics than just geometry information

(Gorti et al 1998)

(2) The generation of product data models that

embody design rationale and knowledge that

intend to promote the share and reuse of

product data (Rosenman and Wang 1999,

Rosenman and Wang 2001, Simoff and Maher

1998) In their model, the structure is what an

artefact is; the behaviour is exhibited as a result

of a certain structure under given conditions

and results in certain functions being

per-formed; the purpose defines those functions

which are intentional and defines an artefact

and what it does or what it is for

(3) The creation of product data models for a

particular design domain or with special

purposes (Gu and Chan 1995, Shen andBarthes 1995, Zha and Du 2002, Wang andNnaji 2004) A STEP-based model for con-current integrated design and assembly plan-ning of mechanical systems by incorporatingentities of integrated resources into theSTEP-based model (Zha and Du 2002).Furthermore, a constraint-enabled distributedproduct data model capable of incorporatingnot only static relations among design objects,but also dynamic relations/constraints to facil-itate design collaboration (Wang and Nnaji2004)

In summary, most of the current product datamodels are defined in a thoroughly new way and result

in a great deal of redundant information In addition,some product data models have not taken fulladvantage of the matured feature-based parametricproduct data models It is difficult to integrate themwith currently popular CAX systems

Consistency maintenance and system architectureare also mentioned in collaborative CAD systems Theformer is concerned with the model data managementduring the design process (Eastman 1996, Mackellarand Peckham 1998) The latter is the softwareorganisation and construction mechanism of a system,which decides which system characteristics to use thatcould provide the greatest convenience and flexibilityfor collaborative partners (Prasad et al 1997, Ball et al

1998, Mackellar and Peckham 1998, Pahng et al 1998,Stouffs et al 1998)

The competitive market requires rapid productdevelopment Modern network technology is promot-ing the changing of the traditional product collabora-tive development mode The kind of CAD system thatcan work well in this type of situation is listed (Hardt

et al 1998, Mills 1998):

(1) Network-oriented system: the system shouldrun on a network, or the Internet It should beopen for all users

(2) Heterogeneous platforms: Because the users aredistributed, their computer environments arepossibly different to each other Hence, it isessential that a proposed system is run in such aheterogeneous environment

(3) System flexibility: the system open mechanism

is required to permit the addition of newcomponents as needed, i.e., extending thesystem modelling capability

(4) System stability: a collaborative system has tosolve the conflicts between the system locationdistribution and the system integrationmanagement

These four features or requirements of a system can

be concluded as the open system Furthermore, there

also have been extensive research works carried out

aimed at developing methodologies and prototype

systems to facilitate distributed design collaborations

There exist three categories of collaborative design

systems, namely, web-based framework, the traditional

client–server paradigm, and agent-based architecture

Web-based collaborative design systems are developed

by mainly adopting the WWW as a collaboration

platform with the web server working as a repository

of design information that can be accessed through a

web browser over a network such as the Internet or an

Intranet (Cutkosky et al 1996, Shen and Wang 2003,

Tamine and Dillmann 2003) The ability to update and

maintain web-based systems without distributing and

installing software on potentially thousands of client

computers is a key reason for their popularity

However, the life-cycle of each collaborative design

interaction between a client and a server is only

unidirectional information flow process This

charac-teristic makes it very difficult to realise effective

interactive design collaboration by a web-based

system

The traditional client–server paradigm usually aims

to facilitate designers in a more interactive design

collaboration process (Mervyn et al 2004, Hu and

Wang 2005, Wong et al 2005) There are several

benefits of using this paradigm (Aderounmu 2004): (1)

it provides clean and simple semantics which make the

binding of distributed computations easy; (2) it is

efficient in that the procedure calls involved are simple

enough for the communication arising to be fast; (3) it

is capable of providing secure and highly reliable

communication However, each system has its own

client program which serves as its user interface and

has to be separately installed on each user’s personal

computer Meanwhile, such a type of system is difficult

to extend These problems result in more support cost

and decreasing productivity

Agent-based collaborative design systems are

con-cerned with how a group of software agents can

cooperate with each other or human designers to

collectively manipulate design information and

knowl-edge and solve design problems Agents have mostly

been used for supporting cooperation among

de-signers, providing semantic glue between traditional

tools, or for allowing better simulations (Shen and

Wang 2003) Although agent technology has been

considered by many to be promising for developing

collaborative design systems (Shen and Barthes 1997,

Brazier et al 2001, Gero and Kannengiesser 2004,

Kannengiesser and Gero 2005, Gero and

Kannengies-ser 2006), most of the systems that have been

implemented so far are domain dependent, and are

intended for integrating legacy design tools Suchsystems are still at a proof-of-the-concept prototypedevelopment stage

Several disadvantages that have not been wellsolved in previous researches but can be effectivelydealt with by the solutions proposed in this study: (i)

an integrated system does not seem able to meet thecomplex design requirements needed in a multi-disciplinary environment (Ball et al 1996, Ball et al

1998, Mackellar and Peckham 1998) For instance,each item on the system will be communicated to allusers; (ii) a distributed-integrated mode works well in afixed environment (Prasad et al 1997), but the centralunit should run in safety and stability; (iii) the mostobvious feature of a discrete mode is its flexibility,without a central control unit (Stouffs et al 1998), butmany model interpreters are required between differentdomain systems; (iv) a staged-based system solves theflexibility of a system (Mackellar and Peckham 1998),but it requires a great deal of AI work to develop thesystem

As for the requirements, they are characterised bythe following features for a collaborative design system:(1) distributed design project management tools should

be integrated; (2) design tasks should be managed in away in which everyone involved in the design processunderstands the rationale behind key design decisions;(3) data management tools are needed to acceleratedesign development cycles by facilitating data reuse andsharing, and protecting it from accidental changes; (4)popular software and its SDK module should beintegrated, so that the extra burden imposed ondesigners to get familiar with the system can be kept

as low as possible; (5) multi-phase communication tools,e.g message, whiteboard, application sharing, and so

on, need to be provided to facilitate the design edge sharing and design work cooperation amongdistributed designers; (6) The framework should sup-port the easy integration of heterogeneous software andhardware tools used by distributed designers, providingeasy access and exchange to data and design knowledgeamong the designers

knowl-3 Methodology of the research and technologicalrequirements

3.1 Methodology of the researchThe research approach that has been adopted in thiswork is illustrated in Figure 1 The different activities

of the research are conducted as follows:

(1) An extensive literature survey is performed

in order to identify the characteristics ofthe frameworks that support collaborativedesign (see the ‘A1’ of Figure 1) The analysis

helped to pinpoint several technological

requirements

(2) The learning requirements and objectives are

identified by performing a survey in the vehicle

administration and the several automotive

driving training schools within Taiwan (as

shown in ‘A2’ of Figure 1) The results are

mapped with the previously identified research

issues and a list of requirements for a

colla-borative design of imseADL is produced

(3) The ‘B’ of Figure 1 shows, computer integrated

design reference architecture is chosen because

it is considered to be clear and flexible to model

the activities, information, knowledge,

loca-tions and organisation point of views in order

to support collaborative design of imseADL

The modelling technologies, e.g UML for

information modeling and IDEF0 for activity

modelling, are used to represent and describe

the above point of views

(4) The activities and knowledge are modelled

using the information acquired from the motor

companies, the departments and stations of

motor vehicle, as well as automotive driving

training schools approached during the field

survey and from the literature review (see ‘C1’

of Figure 1)

(5) A collaborative design architecture that

ad-dresses the research issues is generated The

architecture is presented in detail in this study

(6) A prototype of the proposed collaborativedesign framework is being implemented andsome of the results are presented

3.2 Technological requirementsThe literature review has highlighted several technolo-gical requirements that must be addressed in order todevelop enabling technologies for this type of systems.These are:

3.2.1 Immersive VR driving sceneCreating content of virtual world for the imseADL isdivided into 2 phases: 3D modelling and 3D simula-tion During the phase of 3D modelling, sophisticated3D modelling software packages are used to buildrealistic 3D objects and the surrounding environment

In the phase of 3D simulation, behaviours areembedded into different objects so that they canbehave and interact with each others Moreover, theinteraction between users and the virtual world has to

be programmed in this stage The developmentconceptual procedure of the imseADL is illustrated

1996, Liang and Pan 2006, Liang 2007) This approach

facilitates the integration with the design knowledge

and supports a range of engineering applications The

model data are provided in real time, and it captures

the development progress Model data are also

visualised through 3D virtual model geometry

Mean-while, the virtual learning site in the system is

constructed based on the scenes of a real-life practical

place in the training centre affiliated to the Motor

Vehicle Supervision Office in Taiwan Several learning

items are included in this virtual site and a

configura-tion of the driving site is shown Figure 3(b) (Liang

2009) Finally, the driving scene developed in this study

can be immersive and interactive with a head-mounted

display and a tracker This is shown in Figure 3(c),

which illustrates the use of software and hardware in

developing the scene and displaying the results

3.2.2 Communication tools and engineering

applications

To support communication between distributed team

members the reviewed systems provide synchronous

and asynchronous collaborative tools The former is

used for real time communications, e.g video/audio

conferencing, whiteboard, chat zones and sharing

models to offer a virtual meeting environment The

latter is used in no-real time communications, e.g

email, file downloading from a database, etc

Effective collaborative design development could

be achieved by using engineering applications that

support the correct engineering decision making These

are the applications that need to be performed

collaboratively The following three approaches have

been supported by the researchers:

(1) Common access of design data: the

collabora-tion is achieved by sharing product data

(Abrahamson et al 2000, Rezayat 2000, Chung

and Kunwoo 2002, Qin et al 2003) There is no

real-time visualisation of the geometry The

data, mainly design data, are downloaded from

an information system

(2) Collaborative visualisation of the component:this approach allows the engineers to convertthe solid model previously designed into a 3Dvirtual geometric model Such a model can bevisualised in real time, but not modified, overthe internet (Chang et al 1999, Zhuang et al

2000, Sevy et al 2000)

(3) Collaborative design of the component: thisapproach allows the geographically distributeddesigners to visualise and modify the productgeometric model in real time (Qiang et al 2001,

Su et al 2002)

3.2.3 Knowledge representation

To have an accurate and faster decision makingsupport with some level of automation, knowledgerelated to design should be captured There are severaltypes classified in knowledge representation:

(1) Data of product: this type of knowledge has thedisadvantage that the data still need to beanalysed and applied to the specific problem,such as product specifications, CAD file, designanalysis and so on

(2) Research of cases: this approach is timeconsuming because the relevant informationneeds to be found, understood and applied.(3) Constraints of product life cycle: this knowl-edge is available most of the time from theexperience of the engineers, in books or otherdocuments The decisions taken during thedevelopment of product may be limited bytechnological, processes, resources, material orother considerations

Research effort (Chang et al 1999, Rodgers et al

2001, Shi et al 2001) has been made to capture designrules in the form of ontologies or artificial intelligent

Figure 2 The conceptual procedure for generating imseADL [9]

rules to support isolated applications However, the

proposed systems do not provide the capability to

share these rules in real time or through direct

interaction with the engineering applications One of

the approaches adopted is to store the constraints in a

database and provide a search engine

In this study, it is necessary to have a distributed

source of knowledge to support the different activities

The driving training knowledge model is built andreferred to in the previous paper (Liang 2010), and itaddresses such learning requirement because it is aninformation model that captures procedure of test andthe rules Its data integrity is captured as a result of theway the model represents the training constraintsimposed on the model data definition The drivingtraining knowledge model is the source of informationrequired to support the decision making during theengineering applications

4 Web-based collaborative design architecture forimseADL

This section presents the system architecture of the unitagent-based open CAD (Java application components)system and its relative modules A unit is a reusablesoftware package or application (as shown in Figure 4)

A standard application has two main parts, mentation and data The interaction between twoapplications is through the database In fact thisinteraction is limited to the data sharing For thisreason, the code reuse or system function sharing isimpossible A unit-based application provides opera-tion services containing the data operation and methodoperations in its implementation (in Figure 4(b)) Aninterface file is coupled with this service, in which therevealed data and methods are described If a unit-based application works as a server, the interface file isthe medium connecting the server and one or moreclients A unit-based wrapper can be used to reveal itsdata operation in a traditional application (as illu-strated in Figure 4(c)) In the reuse process, a unitworks as a server A client is a remote applicationlocated at the same or different machine Afterreferring to the specification in the interface file, aclient designer can know what data and methods theunit revealed and how to operate them It should benoted that reuse is on the implementation or program-ming level, which is different from the remoteoperation To support unit-oriented development,several standards and tools are available, e.g theComponent Object Model, the Object ManagementGroup’s Common Object Request Broker Architec-ture, and the Enterprise Java Beans

imple-The primary feature of a unit is its reusability,meaning that a unit is a programmable softwarepackage For this reason, a new application can beassembled from existing software units (Figure 5) Ingeneral, the unit-based development has two aspects:the development of a reusable unit (server side) and thedevelopment an application using those units (clientside) In the imseADL design case, the basic elementscan be designed as reusable software units, and then

‘assembled’ into a driving site for product design

Configuration of driving site [9] (c) Tools and devices for

developing immersive VR driving platform

This unit-based development approach can bring two

benefits for application

(1) Time, function and cost – the reuse of the

existing software units allows a designer to put

more focus on assembling rather than coding

from the beginning, which can shorten the time

to delivery Since the pre-built units have been

pre-tested, the performance and function

should be reliable The risk and the time to

delivery are reduced, and the cost is hencereduced

(2) Open and flexible – the unit-based developmentapproach is based on a scene explorer where theunits come from all over the world and finally aproduct (i.e application) is produced Thisprocess is flexible because the unit resource isnot limited The application is also extensiblebecause new units can be added and existingones can be replaced

Furthermore, the independence of a unit allows it

to work as a system unit or as part of a large system.ORB, COM and EJB are sometimes called distributedobject ‘middleware’, because they mediate betweenunits to allow them to work together, integrating theminto a single, functional whole (the integration ofCOM-CORBA extends the COM running environ-ment out of a Windows platform) A distributedsystem composed of dozens of unit-based applicationsprovides the following features (Saiedian et al 2002):(1) location independence – unit-based applications donot need to exist in the same executable file, run in thesame process, or reside on the same system to invokeparticular functionality; (2) platform independence –unit-based applications do not necessarily reside on thesame host; (3) programming language independence –unit-based applications can interact regardless of thelanguage used to construct each unit

According to the above advantages, the aim of thispaper is to build a unit-based design system supporting

collaborative imseADL development To improve the

self-maintenance capability of each unit, it is designed

as an agent called a unit agent There are the several

basic characteristics listed:

(1) Mode of system – the unit mechanism and the

web-based management facilities – the interface

manager and design phase manager help to

integrate the system and manage the project

(2) Unification of system – the unified units and

the unified operation interfaces make a unified

system compared to traditional systems

(3) Stability – the scene explorer can be used in

distribution, sharing the same unit agents

(virtual elements) The unit mechanism

inte-grates the system tightly

(4) Flexibility – since the distributed unit agents

and the scene explorers are separated in the

design system, they can be easily updated

without influencing the whole system In

addition, a new unit agent can be freely added

to the unit agent family

(5) Reusability – many of the external design

resources can be reused if they are designed as

units For example, the design of a typical car

can be customised as required

(6) Heterogeneous platforms – the unit agents and

scene explorers can run in different operation

platforms, which make it possible to

collabo-rate in a heterogeneous environment

Based on the analysis of the requirements for a

collaborative design system identified in Section 3, a

unit agent-based system is proposed It aims to

facilitate, rather than automate, the management and

coordination of a collaborative design process where

multidisciplinary designers or design teams involved

are geographically and temporally dispersed As shown

in Figure 6, the architecture is structured in a levelled framework: information, application and enduser level In such a system, the end user level issituated in the user’s desktop and is connected to theapplication Web server (application level), which inturn is connected to the information database (in-formation level)

three-4.1 Architecture of unit agent-based open systemThe virtual elements and scene of automotive drivingsite, such as the car, wall, street lamps, traffic signs,door and window elements, etc., can be created in thisstudy and is based in a feature-based approach Eachelement is design as an independent software unit withfull functions It is separated from the scene explorer,i.e., the design interface, which is also designed usingthe unit mechanism To improve the self-maintenancecapability of each unit, it is designed as an agent called

a unit agent

For convenience, those unit agents encapsulatingcommon components can be collected into a database.These unit agents and all scene explorers are managed

by web-based interface manager The interface ager plays a similar function to the interface repository

man-in CORBA (OMG 2009) Through this man-interfacemanagement, a designer can know the service of aunit agent or scene explorer, i.e., its revealed data andmethods Another important module is called designphase manager, which manages the collaborativeleague and design activities Since the design leaguemight be dynamic and distributed, those members canregister themselves in the design phase manager and avirtual team will be formed

In a collaborative design part, the scene explorer isavailable for each designer, and those separated unit

agents are sharable for everyone The interface

manager is the middle medium between the scene

explorer and those distributed unit agents Designers

can join the phase anytime by starting up a scene

explorer and registering in the design phase manager,

independent of where they are The four modules, unit

agent, interface manager, design phase manager and

scene explorer, are described in more detail

4.2 Unit agent model

The purpose of a unit agent is to encapsulate a virtual

element As a unit shared and operated by multiple

users in a collaborative design environment, it should

have the following characteristics: (i) parameterised

and serialised form; (ii) multi-views; (iii)

understand-able; (iv) self-managing; (v) accessibility The first three

characteristics are part of the modelling technology,

the fourth is part of the management, and the last one

is dependent on the system architecture To support

these requirements, the unit agent adopts the

sketch-oriented model (as shown in Figure 7) to represent the

instance model The agent mechanism is added to

manage the instance model while the unit mechanism is

used to integrate unit agents and scene explorer The

infrastructure of a unit agent is shown in Figure 8

Several items of a unit agent are explained as follows

4.2.1 Instance modelThe instance model contains both the data andmethods To support the multi-views representation,the model is realised by common data and methodsbinding multiple disciplines specific data and methods.For a virtual element of driving site, the disciplinesinclude mechanical, vehicle and industrial design Acomplete discipline view includes both the commonand specific data and methods In a car unit, forexample, the method ‘calculate_body_size( )’ belongs tothe common method because the ‘dimension’ is arequired common data for all designers; while themethod ‘car_motion_calculation( )’ is a special one forthe vehicle engineer The model is the combination offormal data, functional data and administration data(as illustrated in Figure 7) Formal data depict thestructural or physical information of a virtual element.There are four parts included in this item: geometry,attribute, hierarchy and linkage The geometry ex-plains the topology and dimension properties; theattribute depicts physical data such as the material andtexture; the hierarchy and linkage represents therelationship of the unit agent with other unit agents.Functional data describe the information related towhat an element is for, what is does and why it is what it

is It is decomposed into four types: objective, function,

rationale and behaviour The objective explains the

needs and intentions of designers; the function

de-scribes what the element does; the behaviour represents

the working principles of the element and logical

actions or influence on other elements; the rationale

shows the reasons or justifications of decision in terms

of selecting values for structure variables to satisfy

behaviour constraints or values The administration

data include the information for maintaining and

controlling the element data in the design stage It

contains six portions: team, file version, operation,

constraint, authority and alternative The team includes

two aspects of messages: that of the designer league

message depicts the related designer’s team and their

responsibility, domain and communication address

The unit league message shows the related unit agents

and their locations; the file version serves to capture the

element data evolutionary history; the operation

watches the actions operating on a unit agent; there

exist various constraint relationships among the

embodiment data and functional data in the form of

formula, ranges, or rules To avoid the data being

operated without any control, the property of authority

can be added to limit the permission of designer access

to the data; the alternative data gather related similar

element structures, design methods, properties and so

forth, which can be alternatives for design

4.2.2 Agent mechanism

The task of the agent mechanism of the unit agent is to

maintain the data automatically, i.e monitoring the

change on the data, maintaining consistency andcoordinating with other unit agents The informationmanagement includes four sections: team, operation,constraints and file version (as shown in Figure 8) Theteam management is responsible for the connectionand configuration of related unit agents; the operationmanagement records the design stage, e.g unit agent’sevolution process and interactions with others; anothertask of operation management that coordinatesthe design activities; the constraint managementmaintains the consistency of the model data; whilethe file version management captures the evolutionhistory of the unit

4.2.3 Unit propertyThe unit property is the lists of revealed elements,including both the data and methods It can bequeried by clients through the interface file whichcontains the service operations for purpose ofcommunication or interaction (Figure 8) Theseservice operations can be decomposed into threeparts: data, implementation method and managementmethod The data operation is usually in the form ofGet_Var( ) or Set_Var( ), which is used to access orreset the data of a unit It is necessary to point out thedifference between the specification and the functionaldata of a virtual element The functional data showthe design objective or function of an element; whilethe specification describes how to operate or reuse therevealed elements In summary, a unit agent is anindependent, intelligent, reusable software package

with sufficient capabilities to support distributed

collaborative design

4.3 Web-based interface manager

The web-based interface manager plays the role of

managing the distributed unit agents and scene

explorer The interface manager stores the interface

files of all related unit agents and scene explorers It

provides the function of registering, browsing, and

recording When a new unit agent for an element or

assembly of driving site is designed, its interface is

registered in the interface manager The interface file

can be viewed in the browser of the interface

manager If a unit is selected to be used, the user’s

message containing information regarding discipline

and contact will be recorded in the interface There

are two coordinating purposes about the message: (i)

let users know which users are related to this unit

agent; (ii) sent to the unit agent and saved as the

team information to let the unit agent know who is

related

4.4 Web-based design phase manager

The client–server mode is adopted on this module

Meanwhile, it provides four kinds of functions: the

project management, the team management, the

knowledge management and the design coordination

board The project management depicts the project’s

purpose, planning and tasks and records the design

progress of each partner (Project Management

In-stitute 2008) The task of the team management is to

manage the user registering to and quitting from the

phase as well as storing the user’s message containing

the information regarding discipline and contact The

knowledge management, for the system administrator

to maintain and upgrade the database includes entity

data and distributed driving training knowledge

model The design coordination board, includes video

conference, whiteboard, chat zone and Email, is a

coordination space for design conflicts arising in the

process Through design phase manager, a partner can

obtain messages about the project, the team, the

knowledge and collaborate with others

4.5 The scene explorer

The scene explorer is where the unit agents are

assembled to produce a project It can be downloaded

from the web It provides the design service and

graphic displaying function The scene explorer offers

four main functions: (i) linking to related unit agents;

(ii) designing a new virtual element based on those unit

agents; (iii) visualising the virtual element in graphic

displaying platform; (iv) revealing the data of the virtualelement To link related unit agents, the designer has

to download the interface file from the interfacemanager, and then incorporate the unit agent into thescene explorer through the interface file Finally, thedesigner can customise the data of the virtual elements.The scene explorer provides a composition set to definethe element composition A data browser is providedfor viewing the data of node in the feature tree (asshown in Figure 11) As for the graphic displayingfunction, a plug-in viewer (Eon viewer) is requiredwhich transfers the data of a unit agent into that of thegraphic system In order to enable the reuse of theelement design in a scene explorer, the element data andsome implementation methods can thus be revealed andreused by other partners This approach will improvethe collaboration quality and speed up the developmentprocess

5 System communication and coordination5.1 Communication of system

In this study, most of the data are saved in these unitagents and scene explorers Because of the unitmechanism, a runtime information exchange modeplays an important role in this system No medium isrequired with this mode except to retrieve the drivingtraining knowledge model and the entity data from thedatabase The data are accessed or set directly at runtime just like its own data There are three typesinvolved in the unit agent infrastructure:

(i) Data exchange is realised through drivingthose revealed methods of a unit in anotherunit To access a large amount of data at onetime, a special method is needed In general,the method ‘Get_Var( )’ is to access some dataand the ‘Set_Var(new value)’ is to set a newvalue for the data

(ii) The revealed implementation methods of aunit can be operated by other units Forexample, the revealed method ‘Calculate_Volume( .)’ in unit A as some unit agent can

be used to calculate the volume of some object

in unit B as the scene explorer

(iii) Management method sharing has two poses: (a) to reuse the management method ofanother unit to carry out a similar manage-ment task in a unit; (b) to drive the manage-ment method of a remote unit once some value

pur-is updated For instance, if the value ofproperty Z in unit A is changed through

‘Set_Var(new value)’ in unit B, the revealedmanagement method ‘Conflict_Detect( .)’ of

unit A can be derived at the same time to

detect the consistency

5.2 Coordination of system

Consistency maintenance is concerned with the data

management of virtual element during the design

process There exist various constraints such as

geometry constraints, function constraints in or

between the virtual elements or between different

views In this study, a unit agent is independent of

others when it is created and the relationship with

other unit agents is based on the instances in a design

project For example, a car door unit agent and a car

body unit agent are independent of each other,

whereas in a design project, a door instance is included

by a body instance In the view of the mechanical

engineer, there exists a dimension constraint between

the door and the door frame of body, but it is difficult

for a unit to manage it automatically The inter-unit

agent-constraints arise from the relationship or

func-tion constraints between unit agents In the unit agent,

the relationship data and functional data are modelled,

which is helpful in setting up the inter-constraints

Applying the above example assumes that the

opera-tion is to change some structural data such as the

thickness of door The dynamical procedure of

constraint setting up is described as shown in Figure 9

The procedure is depicted as:

Step 1:an operation on a door unit agent from adesigner;

Step 2: the door can be determined from theproject name and instance id number;

Step 3: the operation is on some formal data, forexample, to change the width of door;

Step 4: the modification on the formal datainfluences the door behaviour;

Step 5:this affects one of the door functions, i.e.,offers volume to the element below;

Step 6:check the team data and the relationshipdata of the door, the door frame of body is found;Step 7:check out the related door frame of body,which matches the door;

Step 8:find the function of door frame of bodymatching some element above;

Step 9:check out the behaviour for this function,i.e., the assemble interference of the door frame ofbody;

Step 10:check out related formal data related tothe interference;

Step 11:the inter-constraint between this two unitagents are set up finally

6 ImplementationThe proposed system is being developed as a modular-based prototype The driving training knowledgemodel and entity data are implemented as object

oriented database using the object store database

management system (Progress Software 2009) They

reside in the back-end of the system and are accessed

by the engineering applications using standard based

CORBA connectivity The implementation of the

engineering applications uses object oriented

technol-ogies, such as Java and Java3D language Such

applications contain the graphical user interface and

the CORBA connection to the database They receive

input data from the end user and send it to the

database, where the information is processed and a

response is sent as design guides

Figure 10 shows a view of the interaction between

the different portions of the system architecture

presented in above sections, while the prototype of

system implementation for a case study of

collabora-tive design of the appearance of car body is illustrated

in Figure 11(a) A designer collaborates with a

motor company, vehicle administration and driving

training school to consider the design for the

appear-ance of the car body shown in the ‘A’ of Figure 10

This is a virtual element in a virtual driving site The

following section explains in some details the

interac-tion between the virtual elements, the design

knowl-edge model and the engineering applications (i.e

design phase manager)

Virtual element generation in this collaborativeenvironment starts by selecting the ‘design phase’application Figure 11(a) shows the typical GUI, which

is tailored as follows: menu to define an element interms of features (attributes and methods), data inputfields, region of geometric representation and zone ofdesign guide When a user starts the browser, the basicunit agents are embedded in the scene explorer If somespecial virtual elements or assembly is required, theuser can search by means of ‘Name’ (primary key) inthe interface manager and add it to the scene explorer.Meanwhile, the user needs to input general data of theelement, such as name, size, material and colour Bypressing the ‘OK’ button the data are captured in theelement and the user can start defining the element interm of features, as illustrated in the ‘B’, and ‘C’ ofFigure 10 The element is confirmed by pressing the

‘OK’ button A message is displayed in the zone ofdesign guide to hint the design notes and confirm thesuccessful capturing of the data Then, the virtualelement is displayed in the region of geometricrepresentation (as illustrated in Figure 11(b))

The element definition is stored in the entitydatabase (see the ‘C’ of Figure 10) and used byengineering applications to support decision makingafter invoking the required constraints from the

knowledge model for driving training The application,

design for driving training, is presented in the

following section

(i) Design for the driving training applicationThe ‘Design for Driving Training’ application isaccessed by clicking the corresponding icon The firststep is to load element data from the entity database.Then, the analysis is illustrated using the ‘Body’ definedwith the attributes There are two parts analysed: (a)the system analyses the sub-elements of the elementprioritising the critical ones; (b) the designer has thechoice to select any specific feature for its analysis Asillustrated in the ‘D’ of Figure 10, the result of thisanalysis is displayed in the zone of design guide and it isalso stored in a file to be shared amongst thegeographical distributed team The analysis is illu-strated using the ‘Body’ redefined with the followingattributes: engine, 2000 cc; colour, Deep-blue Theapplication invokes the appropriate data from theelement data and knowledge model for driving training

to confirm the suitability of the car body in the drivingenvironment (as shown in the ‘B’ and ‘C’ of Figure 10).The size is outside the constraints of car body, so theapplication sends a design guide to change thedimensions of body, as presented in the ‘C’ and ‘D’ ofFigure 10 The new ‘Body’ defined with the followingattributes: length, 4480 mm; width, 1840 mm; height,

1350 mm, wheelbase, 2640 mm, material, sheet steel.The values are based on the recommendation of themotor companies and vehicle administration Thedesign limitations for car body in traffic are:

Road One wayð Þ : The width should be 3:5 m;the inner radius should be 5:0 m

Parking space : The width should be 2:5 m;the length should be 6:0 m

The designer needs to change those values in theappropriate fields The new data, as shown in the ‘D’ ofFigure 10, are stored in the entity database and virtualelement, as illustrated in the ‘E’ of Figure 10, also bedisplayed in the region of geometric representation Inthis way, the designer is aware of how the outsideconstraints directly affect the geometry of the element.The assembly of other elements, such as the frontdoors and back doors, depends on the door frames ofbody which these are attached The rules for themaximum permitted length, width and thickness are:Length of door frame¼ 0:25  body lengthð ÞWidth of door frame¼ 0:74  body widthð ÞThickness of door frame¼ body thickness

As illustrated in the ‘D’ of Figure 2, front door andback door are defined respectively with the followingattributes:

design system for modelling imseADL (b) Redesign the body

data refer to the design guides (c) Virtual representation of a

car model in virtual driving site

Front door : length; 1260 mm; width;

1003 mm; thickness; 12 mm:

Backdoor : length; 1260 mm; width;

1000 mm; thickness; 12 mm:

The system gives design advice to the designer to adjust

the size of car door

(ii) Other applications

In this system, there are two modes executed, the

real time access of both entity data and knowledge for

driving training, as well as design coordination board

The several advantages are achieved through the two

modes: (a) an engineer interacting with the system,

while the other team members are able to observe and

trace the model development by accessing the results;

(b) two or more engineers are able to use different

engineering applications simultaneously to develop an

element; (c) two designers are able to access the same

engineering application to continue developing the

same element at different times In short, the

sketch-oriented model has enough capability to support the

multi-views modelling, and the agent mechanism is to

maintain the consistency among multi-views

To perform the applications in a collaborative

environment, an on-line meeting phase, such as

Co-Life (2009), can be started during the engineering

activities that require collaboration of the

geographi-cally distributed team members, e.g ‘design phase’,

‘design for driving training’, and ‘design for assembly’

Co-Life provides the following communications tools:

video conference, whiteboard, chat zone and Email As

for the data in a chat or video-conference, a log file is

created and stored automatically after chatting

Meanwhile, a car model, element assemblies, is

built by the application of ‘Design for Assembly’, and

then it is exported in VRML format Finally, the result

is also visualised through the application of virtual

representation (as seen in Figure 11(c))

7 Conclusion

This study has presented a novel approach of a system

architecture that guides the generation and

implemen-tation of a web-based collaborative design system for

modelling an imseADL platform, a unit agent and

knowledge engineering are adopted in this system A

demonstration of its application in the development of

imseADL has also been presented

Each basic element of driving site is designed as an

independent unit encapsulating the entity data and

implementation methods An agent mechanism is

incorporated into the unit to maintain the consistency

To manage these distributed unit agents, a web-basedinterface manager is provided to manage their serviceinterfaces The scene explorer that is based on thesedistributed unit agents acts as the user interface toconstruct a project In a collaborative design stage, theweb-based design phase manager manages the dynamicdesign league and the project Multiple membersdesign the virtual element from different views in theirscene explorer, but share the same unit agents

To integrate and share the information and edge available in geographically distributed motorcompanies, vehicle administration, and driving trainingschools, applications based on CORBA reference modelhave proven to be essential Besides, the interoperabilityamong the different heterogeneous platform is alsoachieved by using the CORBA standard The applica-tion of a feature-based approach in this collaborativeenvironment has provided the integration between theengineering applications and driving training knowl-edge However it has limited the geometric representa-tion of complex virtual elements In addition, thegeographically distributed team members could visua-lise the entity data in a geometric virtual element.Finally, the proposed approach does not aim toreplace existing systems but rather to be a support toolfor communicating and sharing knowledge among thegeographically distributed partners The implementation

knowl-of this system could be considered feasible among thepartners of one industrial design group or extendedenterprise, e.g game design, architectural companies,exhibition planning, etc Such a system will lead to thedesign of better and more cost effective projects,developed in a shorter period of time Our current work

is focused on the system architecture, which has beenextensively tested Our future work will focus on theimplementation of the unit agent model, e.g., the agent-based self-management functions As for the quantita-tive result and evaluation of the proposed system ineffectiveness, these issues will be also considered in thefuture

AcknowledgementsThis research is supported in part by the National ScienceCouncil in Taiwan under contract number NSC 99-2631-S-132-001-CC3 Meanwhile, important parts of the system,especially the user interface and programming were devel-oped by the students J.W Ma and Q.W Iv

ReferencesAbrahamson, S., et al., 2000 Integrated design in a servicemarketplace Computer Aided Design, 32 (2), 97–107.Aderounmu, G.A., 2004 Performance comparison of remoteprocedure calling and mobile agent approach to controland data transfer in distributed computing environment.Journal of Network and Computer Applications, 27 (2),113–129

Ball, N., Murdoch, T., and Wallace, K., 1996 A framework

for design object evolution In: J.S Gero and F

Sudweeks, eds Artificial Intelligence in Design ’96, 77–96

Ball, N., Matthews, P., and Wallace, K., 1998 Managing

conceptual design objects In: J.S Gero and F Sudweeks,

eds Artificial Intelligence in Design ’98, 67–86

Brazier, F.M.T., et al., 2001 Compositional design of a

generic design agent Design Studies, 22 (5), 439–471

Chang, H.C., Lu, W.F., and Liu, X.F., 1999 WWW-based

collaborative system for integrated design and

manufac-turing Concurrent Engineering: Research and

Applica-tions, 7 (4), 319–334

Chung, J and Kunwoo, L., 2002 A framework of

collaborative design environment for injection molding

Computers in Industry, 47 (3), 319–337

Cutkosky, M.R., Tenenbaum, J.M., and Gicksman, J., 1996

Madefast: collaborative engineering over the internet

Communications of the ACM, 39 (9), 78–87

of buildings Journal of Computing in Civil Engineering,

10 (1) January, 78–86

information flows Computer-Aided Design, 28 (6–7),

551–565

Gero, J.S and Kannengiesser, N., 2004 The situated

function–behavior–structure framework Design Studies,

25 (4), 373–391

Gero, J.S and Kannengiesser, U., 2006 A function–

Computing and Cognition ’06 New York: Springer,

407–422

Gorti, S.R., et al., 1998 An object-oriented representation

for product and design process Computer-Aided Design,

30 (7), 489–501

Gu, P and Chan, K., 1995 Product modeling using STEP

Computer-Aided Design, 27 (3), 163–179

Hardt, D., Patterson, R., and Neal, R., 1998 Next

genera-tion manufacturing: a framework for acgenera-tion, executive

overview The Agility Forum Bethlehem, PA, January

Hu, W and Wang, S., 2005 Study on the architecture of

product collaborative design system in mass

customiza-tion base on J2EE In: Proceedings of the Ninth

International Conference on Computer Support

Coopera-tive Work in Design, 24–26 May, Coventry University,

UK, Vol 1, 206–210

ISO, 1994 ISO 10303, 1994 STEP Part 41, Integrated

Resource: Fundamentals of Product Description and

Support Geneva, Switzerland: International Standards

Organization

ISO, 1994 ISO 10303, 1994 STEP Part 11, 21, 42, and 203

Organization

ISO’s, Official Website, 2009 Available from: http://www

iso.org [Accessed 10 April, 2009]

ISO/STEP, 10303-225, 1996 Product Data Representation

and Exchange-Part 225: Application Protocol: Building

elements Using Explicit Shape Representation Geneva,

Switzerland: International Standards Organization

ISO/STEP, 10303-228, 1996 Product Data Representation

and Exchange-Part 228: Application Protocol: Building

Services: Heating, Ventilation, and Air Conditioning

Organization

Kannengiesser, U and Gero, J.S., 2005 Understanding

situated design agents CAADRIA’05, 28–30 April, TVB,

New Delhi, Vol 2, 277–287

Latif, M.N and Hannam, R.G., 1996 Feature-based designand the object-oriented approach Journal of EngineeringDesign, 7 (1), 27–37

Liang, J.S., 2009 Generation of a virtual reality-basedautomotive driving training system for CAD Education.Computer Applications in Engineering Education, 17 (2),148–166

Liang, J.S and Pan, W.W., 2006 Conceptual design system

in a web-based virtual interactive environment forproduct development International Journal of AdvancedManufacturing Technology, 30 (11–12), 1010–1020.Liang, J.S., 2007 A web based 3D virtual technologies fordeveloping a product information framework Interna-tional Journal of Advanced Manufacturing Technology, 34(5–6), 617–630

Liang, J.S., 2010 A web-based automotive refrigerationtroubleshooting system applying knowledge engineeringapproach Computers in Industry, 61 (1), 29–43

Mackellar, B.K and Peckham, J., 1998 Multiple tives of design objects In: J S Gero and F Sudweeks,eds Artificial Intelligence in Design ’98, 87–106

perspec-Mervyn, F., et al., 2004 Developing distributed applicationsfor integrated product and process design Computer-Aided Design, 36 (8), 679–689

Mills, J., 1998 Introduction: towards an informationinfrastructure for manufacturing industry In: J.J Millsand F Kimura, eds Information Infrastructure System

National Center of High-performance Computing, Co-Lifeon-line meeting/speech system, Available from: http://colife.nchc.org.tw/index_en.aspx, [Accessed in 10 May,2009]

OMG (Object Management Group), 2009 Corba Basics,

corbafaq.htm, [Accessed in 5 May, 2009]

Pahng, F., Senin, N., and Wallace, D., 1998 Distributionmodeling and evaluation of product design problems.Computer-Aided Design, 30 (6), 411–423

Prasad, B., 1996 Concurrent engineering fundamentals:integrated product and process organization New Jersey:Prentice Hall PTR, vol 1

Prasad, B., Wang, F.J., and Deng, J.T., 1997 Towards acomputer-supported cooperative environment for con-current engineering Concurrent Engineering: Researchand Applications, 5 (3), 233–252

Progress Software, 2009 Objectstore Available from: http://www.objectstore.net/index.ssp, [Accessed in 25 May, 2009].Project Management Institute, 2008 A guide to the projectmanagement body of knowledge (PMBOK Guide).Fourth Edition

Qiang, L., Zhang, Y.F., and Nee, A.Y., 2001 A distributedand collaborative concurrent product design systemthrough the WWW/Internet International Journal ofAdvanced Manufacturing Technology, 17 (2), 315–322.Qin, S.F., et al., 2003 A framework of web-based conceptualdesign Computers in Industry, 50 (2), 153–164

Rezayat, M., 2000 The enterprise-web portal for life-cyclesupport Computer-Aided Design, 32 (2), 85–96

Rodgers, P., et al., 2001 The management of concept designknowledge in modern product organizations Interna-tional Journal of Computer Integrated Manufacturing, 14(1), 108–115

Rosenman, M.A and Wang, F.J., 1999 CADOM: A ponent agent-based design-oriented model for collabora-tive design Research in Engineering Design, 11 (4),193–205