E-cooperative design among mechanical and electrical engineers: … › file › index › docid › 333844 › ... · 2020-05-26 · E-cooperative design among mechanical and electrical

HAL Id: hal-00333844https://hal.archives-ouvertes.fr/hal-00333844

Submitted on 24 Oct 2008

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

E-cooperative design among mechanical and electricalengineers: implications for communication between

professional culturesBenoît Delinchant, Vincent Riboulet, Laurent Gerbaud, Philippe Marin,

Frédéric Noël, Frédéric Wurtz

To cite this version:Benoît Delinchant, Vincent Riboulet, Laurent Gerbaud, Philippe Marin, Frédéric Noël, et al.. E-cooperative design among mechanical and electrical engineers: implications for communication be-tween professional cultures. IEEE Transactions on Professional Communication, Dec 2002, –, France.pp.231 - 249. �hal-00333844�

https://hal.archives-ouvertes.fr/hal-00333844

https://hal.archives-ouvertes.fr

IEEE TRANSACTIONS ON PROFESSIONAL COMMUNICATION, VOL. 45, NO. 4, DECEMBER 2002 231

E-Cooperative Design AmongMechanical and ElectricalEngineers: Implications forCommunication BetweenProfessional Cultures

—BENOIT DELINCHANT,VINCENT RIBOULET,LAURENT GERBAUD,PHILIPPE MARIN,FRÉDÉRIC NOËL,AND FRÉDÉRIC WURTZ

Abstract—This paper looks at the collaborative design activityinvolved in a design experiment of an electromechanical plunger.Much of the coordination was achieved through internet-basedcommunication. As mechanical and electrical researchers involved inthe design project, we discuss the information exchanges highlightedby our different professional cultures and relate how these exchangeslead us to propose some methodology to improve the efficiency ofvirtual meetings. Moreover, we show the need for new communicationtools, ones dedicated to specific tasks that are not currently supported,especially shared concept formalization among technical experts.

Index Terms—Collaborative design, electrical and mechanicalengineering, internet-based information exchange, professionalculture, shared objects, virtual teams.

Manuscript received February 27, 2002;revised June 17, 2002.B. Delinchant, L. Gerbaud,and F. Wurtz are with theLaboratoire d’Electrotechniquede Grenoble (LEG),UMR-5529 CNRS-INPG/UJF,EMSIEG, BP46,F-38402 Saint Martin d’Héres Cèdex,France(email: [email protected];[email protected].;[email protected]).P. Marin, F. Noël, and V. Ribouletare with the Laboratory“Sols-Solides-Structures” (3S).UMR-5521 UJF-INPG-CNRS, BP 53,38041 Grenoble Cedex 9, France(email: [email protected];[email protected];[email protected]).IEEE DOI 10.1109/TPC.2002.805149

Increasingly, the design oftechnical products tends tobe a collaborative activity inwhich concurrent engineeringmethodologies are developed inorder to involve the different pointsof view on the product, all alongits life cycle. In order to increaseinformation exchange efficiencyand to ensure the best integrationof the different experts involvedin the design process, new toolsand new methodologies have beenproposed. Our research deals withthese concurrent engineering andcollaborative work approaches.

Design activity often requiresthe collaboration of designersfrom different skills and fromdifferent professional cultures.This trend is pushed by theevolution of the products becoming

more and more complex, thusnecessitating optimization fromany point of view. In parallel, theglobalization of industrial activityand decentralization of manymanufacturing processes leadcompanies to work in relation tovery distant collaborators.

The expansion of internet-basedtools has opened newopportunities for collaborativework improvement. Our researchfocuses on the feature specificationand development of such tools.

In this paper, we first present aliterature survey to situate ourstudy in the field of collaborativedesign. We discuss the availabletools supporting collaborative workover the internet in an industrialcontext. We address electronic

0361-1434/02$17.00 © 2002 IEEE

Authorized licensed use limited to: IMAG - Universite Joseph Fourrier. Downloaded on October 22, 2008 at 04:10 from IEEE Xplore. Restrictions apply.

232 IEEE TRANSACTIONS ON PROFESSIONAL COMMUNICATION, VOL. 45, NO. 4, DECEMBER 2002

collaboration in the context ofthe negotiation between theprofessional culture of mechanicaland electrical engineers. Finally,we detail the contemporarysolutions for collaborative work.

In the next section, we detail thecollaborative experiments we havemade. The hypothesis as wellas the chosen design example(an electromechanical plunger:EMP) are presented. We detailthe different kinds of experimentswith their objectives, and we focuson two technical aspects whichhave to be solved thanks to aconfrontation between the culturesof the electrical and mechanicalengineers.

We then discuss and present theresults of this work that helpanswer the following questions:• What are the communication

typologies (formal, informal,synchronous, asynchronous)and the tools able to supportthem?

• What kinds of different meetingsappear?

• Which information is exchanged,what are the concepts and thenew requirements of a tool ableto support such exchange?

Finally, we present a frameworkfor the new tools we started todevelop. They are dedicated tosupport complementary aspects ofcommunication in a multiexpertdesign activity over the internet,providing communication featuresnot available in present-daycommercial solutions.

LITERATURE SURVEY ANDWORKING CONTEXT

Industrial Context: CAD orPDM to Share Product Data Thechallenge for software developers isto provide users with solutions thatallow the best compromise betweencommunication among themselves,and ease of use in his or her dailyactivity. The commercial solutionscommonly developed in the CAD(computer-aided design) contextfor several years comprise twocategories.

The first category requires everyparticipant in the design process towork around the same CAD/CAM(computer-aided manufacturing)software and to provide lotsof “expertise” modules in thatsoftware (geometric modeling,various simulations, differentmanufacturing or assemblyprocesses, drawing and billingof material edition, etc.),in anattempt to cover the needs of eachparticipant. This is the choiceof tools such as Pro/Engineer,Catia, Unigraphics, Ideas, etc.In this way, everybody in theproject is working around thesame geometric model [1], andthere is no need of informationtranslation, or if there is such aneed, the translation is providedby the expert module itself.

The second category allows usersto work with their preferredspecific tools but also imposesa common PDM (product datamanagement) software such asAgile, Windchill, Enovia, Pro/PDM.The goal is to ensure that theavailable data is always unique, upto date (maybe keeping a historyof versions), and to avoid the needof asynchronous data transfers.The collaboration between theparticipants is organized throughthe PDM system sharing computerfiles representing the product.As in the previous categoryof solutions, this approachdoes not provide synchronouscollaboration. Moreover, it does notavoid translations between experttools, through the various standardfile formats for three–dimensional(3-D) geometry (IGES, SET, VDA,STEP, etc.). One can also notethat there is a lack of standardexchange formats for other kindsof information.

In this paper, we show that thereis actually a need to develop newsoftware tools that will supportsynchronous and asynchronousdialog between technical experts,providing them with the abilityto inter-trade a formalization ofshared concepts.

Cultural Aspects Our researchproject focuses on collaborationamong mechanical and electricalengineers, who have differentscientific and technical cultures,their own specific semantic fields[2], different ways to solve designproblems, and different simulationtools that do not manipulatesimilar concepts, information,or parameters. As studies ofcultural aspects propose [3], onemay distinguish several aspects:national culture [4], corporateculture, professional culture, andbranch culture. In our experiment,national culture is the samefor everybody (it is not a factorinfluencing the design processor the exchange of informationlike in [5]). Branch culture is notrelevant, and corporate culture isnot supposed to be a major factor(this could be discussed as all thedesigners are researchers, thushaving probably some commonvalues). This said, the majordifference between the two teamsis professional culture.

A Mechanical Point of View: Ourperception of the mechanicaldesign culture is that it is mainlyorganized around tasks sharedamong several participants, eachcompetent in a specific subfield. Inthis context, each designer oftenhas specific goals, manipulatesspecific tools and knowledge, andmay appear to belong to a specificcultural domain [3]. With this inmind, one can also refer to theconcept of “worlds” as defined byMer [6]. This concept is based onthree sociological notions.

• The ACTION LOGIC, taken from[7], which relates to goals andissues of involved people and tothe action itself.

• The SCALE OF VALUE, taken from[8], which leads to some rulesto evaluate a technical solutionwith respect to various criteria,and which is used especially tojustify the action.

• The COLLECTIVE KNOWLEDGE,which refers to sharedknowledge, along with


DELINCHANT et al.: E-COOPERATIVE DESIGN AMONG MECHANICAL AND ELECTRICAL ENGINEERS 233

conventions, implicit or explicitrules manipulated by people inthat world.

While, from the analysis of aparticular company, Mer proposesto distinguish the scientific world,the industrial world, the customerworld, and the buyer world, onecan speak in our case about thedesigner world, the simulationworld, and the manufacturingworld. Each of them has its ownaction logic, collective knowledge,and scale of value. In sum, they areof different professional cultures.

Let us add that the way mechanicalengineers are designing hasconsisted for several decades incombining standard technologicalcomponents with some kinds ofstructural innovations. They alsomanaged loop simulations forchoosing material, dimension,manufacturing, strength, orbehavior, until they can get asatisfactory product definition.This way of doing implies intensiveexchanges between involvedactors. This is a special featureof the mechanical engineeringculture.

The Electrical Engineers’ Point ofView: From our point of view,when designing electrical deviceslike a motor, a transformer, or aplunger, the designer must have aglobal vision of the device for thefollowing reasons:

• Electromagnetic phenomenonis linked to the thermal andmechanical phenomena. Forexample, the current in thewindings or the magnetic fluxin the iron parts generateslosses that are at the originof the thermal phenomenon,which, in turn, changes someelectromagnetic characteristicslike the resistance of thewindings. In the same way, themechanical constraints andlimits must be known since thepossible values of the air gapsor the section of the magneticmaterials (like iron) depend onthem.

• The electromagneticphenomenon propagatesin all the devices around(theoretically in all the space).

This necessity of a global visionexplains why electrical designersoften work alone or in a small team.The electrical designer works withsimulation tools that help portrayvarious physical phenomena. Thisis a special feature of electricaldesign culture.

In spite of this traditional way ofworking, it has become apparent inthe last few years, that devices arebecoming more and more compactand complex. Their electricaldesign requires very specific skillsin fields such as power electronicsor electromagnetism, skills thatare distributed between severalspecialists. Thus, collaborativedesign processes must bedeveloped and improved.

Industrial Design Process ofElectromechanical Products: Letus point out that in mostelectrical companies, in therecent past, electrical deviceswere still designed in two distinctsteps (design of magnetic partswithout involving significant dialogwith other engineers, and thenpassing the file to mechanicaland manufacturing offices). Thisactivity tends to become morecollaborative, covering the wholeprocess, in order to get optimized ina global point of view. But there isa lack of computer communicationtools able to support the requiredinterprofessional technicalexchanges.

In fact, an important part ofthe design process consists inexchanges between participants ofdifferent professional cultures (forinstance, electrical and mechanicalengineers). Even in each domain,different professional cultures andspecialists need to interact. Ofcourse, those processes alreadyexist, but they have to be improved.

Present-Day Solutions forCollaborative Work: ICT What

are the possibilities of ICT(internet communication tools)as a communication media? Wesurveyed available technologies,in terms of tools that allowcollaborative work over theinternet.

Communication Tools: The firstcategory of software concernsclassic communication needs.Some of these tools are nowwidespread.

Some tools allow technicalstructured data to be shared ortransferred (draft sketches orprecise geometric definition, 2-Dor 3-D, etc.) while others aremostly dedicated to exchangenonstructured information.According to van Luxemburgand Ulijn [9], these differencesin media richness depend on thenumber of social clues that can betransported by the medium. Hence,choosing a good media depends onthe amount of explicit informationused in the activity. This leadsthe authors of [9] to propose aninteresting classification of mediarichness (see Fig. 1).

Relatively little software canput several tools together ina collaborative environment,covering a wide panel of the scaleof Fig. 1. Let us cite MicrosoftNetMeeting, HP Shared-X, and SGIInperson. The last provides theability of sharing 3-D CAD modelsin the whiteboard, which can bevery useful in mechanical partdesign activity.

Dedicated Tools: A new categoryof tools has appeared recentlythat are specifically dedicated tocollaborative technical-productdesign over the internet. Thesetools offer a team of engineers(including design, production ormarketing offices, subcontractors,etc.) a way of working together ona technical activity, sharing dataabout the product in question [10][11].

The functionalities of commerciallyavailable tools of this kind havebeen classified (see Table I). As



one can see, most of these toolsfunctionalities are an integration ofseveral communication tools and aPDM, complete with the ability ofvisualizing a common 3-D model,and sometimes to modify it.

These solutions cannotsupport a satisfactory technicalcommunication among a designteam, if several engineers ofdifferent professional cultureshave to collaborate from differentplaces, and especially withdifferent tools matching theirown needs and practices. Forexample, the main function ofthese dedicated tools, 3-D sharing,is not appropriate for electricalengineers who do not use a 3-Dmodel as a working base.

Organization Tools: Industryclearly asks for some organizationand working methodologies inorder to manage their distributeddesign activity. In particular, two

different aspects are discussedbelow: workflow managementduring the whole design projectand synchronous meetingsorganization.

Presently, PDM software includeproject and workflow managementfacilities. They are evolving towarda “web-based” model, providingeasy accessibility through a simplebrowser to the main functionalities(PTC Windchill, EDS Team Center,Dassault Systems Enovia Portal).Their area of concern is expandingwith the PLM concept (ProductLifecycle Management): theidea here is to integrate everyparticipant of the whole designactivity, including, for example,subcontractors or even customers.

But these widespread industrialtools have two limitations. First,they are based on predefinedworkflow definitions. Someresearch teams are working on

these topics. Let us cite works ofthe APEL research project [12] inthe computer science field whichtries to bring tools to manage theworkflow when a conflict appearsduring creation of software.

Second, there is no organizationtool dedicated to providesynchronous meeting managementfacilities. Recent research [13]tries to give directions for aneffective leadership of virtualteams by closely analyzing theirtypology according to criteriasuch as temporal distribution(synchronous or not), boundaryspanning (in terms of mixingdifferent cultures, for example),the life cycle of the team (discreteor continuous), and the variety ofmember roles.

A Concept for SharingKnowledge: IntermediaryObjects Among the analyzedtools no solution can dynamically

Fig. 1. Media richness in a qualitative scale.

TABLE IAN OVERVIEW OF COMMERCIAL COLLABORATIVE

DESIGN TOOLS [11]



support the definition of a newobject or concept defined from thedialog of two engineers in the flowof their daily work.

That is why we state positivelythat focusing on communicationbetween software [14] anddirect exchanges of predefinedconcepts cannot lead to efficientcommunication between craftsmenor every participant in the designprocess. Thus, we turn towardcommunication between peoplewho are familiar with the projectcontext, can explain their specificconcepts and parameters toeach other, and then defineand dynamically format sharedentities. This approach is based onthe concept of INTERMEDIARY OBJECT

as used in [15], and as defined in[16] as follows:

We simply use the termintermediary to mean thatobjects lie in between severalelements, several actors, orsuccessive stages of a workprocess (intermediary results).We shall thus talk aboutintermediary objects as ageneral way of designatingdrawings, files, prototypes,which mark the transition fromone stage to another, circulatefrom one group to another oraround which various actorsand instruments revolve.

But we also point out the ideathat each of these objects must bedefined, stored, and manipulatedtogether with its contextualexplanation. In this way, everyinformation exchange becomesclear for every actor concernedwith it, without misunderstanding,and the translation proceduremay be defined by each actoraccording to their own knowledgeand practice.

Thus, on the opposite ofthe approach used in SCMsoftware (System ConfigurationManagement), where sharedobjects management is automatedin a way based on workflow andpredefined objects life cycle [17],[12], we choose to provide a more

informal way of creating andmanaging shared information,so that it may be used eitherin scheduled collaborations orin opportunistic interactionalcontexts [18]. With this in mind,we need to look closely at the PACTproject developments [19], wherea study of some domain-specificengineering ontology is proposed.Nevertheless, we assume that,despite every effort that canbe made to define such commonengineering artifacts and processesin a given domain of expertise,engineers may always have todefine new shared concepts andvocabulary dynamically matchingtheir needs in the collaborativedesign work. As noted in [20],[21], and [22], the building of a“common information space” inCSCW should not simply consistof objects, events, e.g., in a shareddatabase, but also should involvethe joint interpretation of theseobjects and events by the actorsinvolved:

Cooperative work is notfacilitated simply by theprovision of a shared database,but requires the activeconstruction by the participantsof a common information spacewhere the meanings of theshared objects are debated andresolved, at least locally andtemporarily. Objects must thusbe interpreted and assignedmeaning, meanings that areachieved by specific actors onspecific occasions of use.

EXPERIMENTS

In this section, we will describethe experimentation, over threesections.

The first presents the designexperiment framework, with thedevice to be designed, and thecontext of work.

The second presents sequentiallyfour collaborative experimentsthat will be discussed in the nextsection.

Finally, the third focuses on twospecific technical problems that

have been treated through the fourprevious experiments.

Device to be Designed andOutlines of the Design Process

An Electromechanical Plunger: Inthis paper, collaborative design isillustrated on an electromechanicalplunger (EMP) [23] detailed in theAppendix and shown in Fig. 2.

The design of such a systemrequires several steps.• Definition of the structure

and choice of material for thedifferent parts, by consideringthe physical constraints ofthe process. For example,the magnetic flux has to beconsidered in some parts butnot in other ones, the machiningof steel modifies its magneticproperties, etc. In this step,manufacturability is also takeninto account.

• Modeling of the physical(electrical and mechanical)aspects of the system by usingcalculation tools with finemodeling. This task allows us toanalyze some phenomena andto have reference models forthe creation of simple modelsdedicated to the sizing.

• Sizing by using optimizationtechniques if possible.

• Definition of the manufacturingprocess and assembly planning.

In every step, contradictionsbetween mechanical and electricalaspects appear. For example,the section of the body must besufficient to assure a magnetic fluxdensity, but also must not be toothick, according to manufacturingprocess constraints. Thus,many choices have to be made,

Fig. 2. Principle of anelctromechanical plunger.



involving several exchanges amongthe participants of differentprofessions. In this design process,several tools must be used so thedesigners may exchange severalkinds of information. Fig. 3 showsan example of 3-D geometrydeveloped by a mechanicalengineer and proposed to theelectrical engineers.

The Appendix first develops atechnical presentation of thespecification of the plunger andthen presents the profession toolsnecessary for its design.

Hypothesis and Context ofWorking: This paper only dealswith collaborative work viainternet, hence at distant places.Face-to-face interaction and phoneexchanges are not discussedand will not be dealt with in thefollowing experiment descriptions.

Experiments: CollaborativeDesign Over the Internet Toachieve the design of theelectromagnetic plunger, three verydifferent design meetings over theinternet have been organized. Thestudy of those meetings allows usto better understand which kind oftools and exchanges are requiredfor a collaborative work over theinternet. Each design session hadvery specific objectives.

Several roles were taken by theparticipants:• the project leader who had to

coordinate the project review;• the customer, defining the EMP

specifications;

Fig. 3. A view of the plunger 3-Dmodel at an intermediate designstage.

• the mechanical designer;• the manufacturing engineer;• the electrical engineer (both

for the characterization of thestructure and the sizing).

However, before presenting thesesessions, we will develop the firstphase of our design experiment.

Forum Tool, SupportingAsynchronous Work: To startthe codesign project, a discussionforum was created for thecollaborative choice of thestructure of the EMP fromspecifications defined by thecustomer. Such a forum waswell adapted to support andto capitalize the asynchronousexchanges between actors.

In this way, the forum was used tosave files in a technical format:• Professional drawing tools.

Their file format cannot bemanipulated by everybodyin the design team (e.g.,SolidWorks, Pro-Engineer, Flux,Mathcad, Pascosma-Eden,etc.). As the forum allows theexchange of any file types, theactors have naturally chosento use screen captures to showthe structure drafts from theseprofessional tools.

• Other software like MicrosoftPowerPoint and Microsoft Paintwere used because they offer theopportunity to create drafts andpictures, and they are availablefor every actor.

• Some designers have drawntheir drafts on paper sheetsand scanned them. Thesedrafts were often completed byexplanations, questions, andremarks (see Fig. 4).

As this exchange mode is tooasynchronous and not sufficientlyinteractive, this experiment hasnot given very satisfying results.

Definition of the PlungerStructure: The goal of thismeeting was to design theplunger’s structure, out of theinitial specification sheet. Theconfiguration of the meeting wasthe following:

• on the mechanical side, theengineers were dispatchedin two different sites withcomputers and specific tools,one site for mechanical design,and one for manufacturinganalysis;

• on the electrical side, all theengineers were in the sameroom with one PC.

The used environment wasNetMeeting with its chat tool, itstool for application sharing, andits whiteboard. When needed,the teams agreed to synchronizetheir exchanges using the phone.This possibility was necessary,since NetMeeting only allowsparticipants to use voice exchangesfrom point to point, hence onlybetween two participants.

As the special functionalitiesof commercial collaborativededicated tools were not reallyinteresting in our case (see thenext subsection), we decidedto use only the nondedicatedcommunication possibilities, suchas the ones found in classicaland free communication toolsdescribed later.

To be able to design a structurefor the device, the following kind ofinformation has been exchanged.

� Information about the electricalphenomena that occur in the EMP.As shown on Fig. 4, some drafts onthe whiteboard were presented toexplain complex phenomena. For

Fig. 4. Example of exchange viathe forum: remarks of the electricalengineers on a structure (draft)proposed by a mechanical designer.



instance, on the sheet of Fig. 5, theelectrical engineers explain howthe magnetic flux is created andhow it propagates in the device.This was also the opportunityto explain to the mechanicalengineers what are the criticalair gaps for this propagation.Air gaps that should be avoidedor minimized in the mechanicalstructure.

� Information about the structurethat the mechanical engineershave proposed. First, the 3-Dmechanical geometric modeler(SolidWorks) was shared on onePC throughout NetMeeting. Thiswas not very successful becauseit was a bit slow over the net.Moreover, electrical engineers werenot familiar with this mechanicalsoftware interface. Second, draftswere made by hand by themechanical engineers on thewhiteboard (see Fig. 6). Thosediagrams gave the opportunity toexplain the solution and to discussthe drafts when some problemsoccurred.

Pretty quickly, this meeting turnedinto simple exchanges betweentwo actors, in a point-to-pointmode. This can be explainedby difficulties synchronizingthe exchanges and using thewhiteboard in a coordinate way.We tried to share an applicationon one PC, but, as previouslysaid and despite the fast internetconnection (10 Mb/s), this wasslow and inefficient. This wasprobably due to “heavy display”

Fig. 5. Sheet presented bythe electrical engineers on thewhiteboard to explain to themechanical engineers the path of themagnetic flux.

of the 3-D geometric modelingsoftware.

The experiment highlighted somelack of efficiency, but at last,the choice of the structure wasmade after a few point-to-pointexchanges.

Sizing the Structure of thePlunger: For this meeting,Microsoft NetMeeting was usedagain but along with Paltalk for itsmultipoint audio facility.

The configuration of the meetingwas the following:• On the mechanical side, the

engineers were dispatched intwo different rooms again: onein a room with a PC and twoparticipants in another roomaround one PC.

• On the electrical side, all theengineers were in two rooms(two in each), but each actorhad his own PC.

• For this structure sizing, someinformation must be exchanged,as follows.

• Equations: an example ofthis is the equation of theforce of the spring. Oneparticipant in the mechanicalcommunity had to design thisspring. This design had to betransmitted to the electricalengineers. They had to size theelectromagnetic structure toproduce a static electromagneticforce able to contain the force

Fig. 6. Manual drawing used toexplain and discuss the structurefor the magnetic core chosen by themechanical engineers.

of the spring. The spring andthe corresponding equationwere discussed during themeeting through oral informalcommunication as well asthrough the chat window (seeFig. 7).

• Values given to some parametersthat must be explained by oneparticipant to the others as wellas the units.

• Meaning of the parameters andthe equations.

An efficient media to explain themeaning of some parameters is,of course, the whiteboard. Fig. 8shows an interesting example ofa whiteboard used during themeeting. On the left side, theparameterization of the modelused by the electrical engineersto calculate the electromagneticforce is presented. On the rightside, a part of the mechanicalstructure and model designedby the mechanical engineers isshown. By having both views onthe whiteboard simultaneously,the participants could link thegeometric parameters used in bothmodels and both communities.This sheet could be used to “link” inboth models the maximum lengthof the spring and other relatedparameters, but this link remainedvirtual in engineers’ minds. Thereis currently no mean in standardcommunication tools to link oneparameter in a mechanical designsoftware to another parameter inan electrical simulation software.Note that this link, its meaning,and its parameters can be seenas a simple example of commonknowledge created dynamically

Fig. 7. An example of the contentof the chat window when thediscussion was about the equationof the spring.



between mechanical and electricalengineers.

A Project Review: The goal of thismeeting was a briefing about allthe work done for the design ofthe plunger. As in the previousmeeting, Paltalk and NetMeetingwere used.

For this project review, eachparticipant had to prepare a talkfitting in a limited timeframe. Amoderator was identified in orderto synchronize and synthesize allthe presentations made.

The meeting began with apresentation of a participantsharing his PowerPoint applicationthroughout the net. This time,the sharing of this “light-display”software was very successful. Thiswas the opportunity to explainagain the specifications andmainly the constraints the teamencountered. Each member ofthe team who was involved in thestudy presented his contribution.The meeting was structured,driven, and very efficient.

Focus on Two TechnicalAspects As the design of theplunger is a joint problem ofmechanics and magnetism, it mustresult from a close interactionbetween both of the professions.This section focuses on twodiscussions among the variousundertaken experiments.

Fig. 8. Whiteboard used to comparethe electromagnetic model and apart of the mechanical model. It wasparticularly used to find the maximallength of the spring in both models.

The Magnetic Problem: Air GapVersus Clearance: The exampleof the air gap illustrates theinteraction of mechanical choiceson the magnetic design.

What is the impact of the clearancearound the plunger and theslacks in the magnetic circuit thatintroduce air gaps and, hence,disturbances in the magnetic flux ?

Initially, this aspect appearedduring the design of the structurewhile using the forum, and thenin synchronous discussionsduring online meetings. The forumappeared to be too asynchronousso that a lot of energy was lostby the participants explainingtheir choices, and it was verytime-consuming. So we decidedto use synchronous meetings tochoose the structure of the EMP.

Problem specifications weregiven by electrical engineerswith the principle draft of Fig. 2.Then, several solutions wereproposed by the mechanicalactors and discussed by theelectrical ones in the forum.Fig. 10 shows an example ofsuch an exchange. Finally, asthere were misunderstandings,a videoconference was used tosynchronize the knowledge ofeverybody on the problems.

In this way, participants on theelectrical side added remarkson the draft created by theparticipants on the mechanicalside. As this was not sufficient,expert rules were formulated bythe electrical engineers to explainsome choices. For example, theshape of the EMP envelope is eithercircular or squared, whenever thesection area is sufficient for thecrossing of the magnetic flux.Finally, a compromise was foundbetween a small thickness withrespect to weight and the costaspects and a sufficient thicknesswith respect to the flux crossingarea and loads.

In the same way, a compromisewas discussed to define the

clearance around the plunger’snail without it having a too largeair gap. The problem is, for themechanical engineer, that theclearance around the nail is veryimportant for its movements, butit is obstructing the magneticcircuit because it creates an airgap in the flux trajectory. Bothparticipants had their own viewand saw different constraints, sothey had to compromise to ensurea good design that respects allmanufacturing, functional, andcost constraints.

The Spring Problem: This problemappeared when the team workedon the equilibrium of the plunger.The element involved here is thespring (see Appendix for detailedexplanation of how the EMP isworking).

During the online sizing meeting,mechanical engineers have giventhe equation that may representthe spring strength dependingon the plunger position. Thisequation was introduced withinthe electrical model, but the sizingprocess did not converge. Thisdivergence was due to unsatisfiedconstraints, particularlygeometrical constraints. Infact, the spring was too strongto be contained in the maximalbounding size allowed by thespecification sheet.

Our first sizing try raisedsome questions about codesignrequirements as it constrained thenatural designer behavior. Afterseveral interchanges between theconcerned designers, the followingchoices were proposed to continuethe codesign:

• an iterative process (try andmiss);

• an increase in the commonknowledge container;

• integration of all knowledge [19],[21].

A natural iterative process wouldbe to ask the mechanical engineersto propose another spring andretry the sizing. But we tried a



better way of codesigning ratherthan a simple “try and miss”methodology.

To avoid many back and forthattempts, we tried to increase thecommon information containerby explaining the magneticconstraints on the spring. Thisallowed the mechanical engineersto have an idea of the springmaximal strength needed. Themechanical engineers could thenredesign the spring trying totake into account these newconstraints.

RESULTS AND DISCUSSION

Our choice of public and genericcommunication tools has shownits possibility to achieve our designgoal (Fig. 9) and to support theemergence of a common culture.But it has also led to efficiencylimitations, due to some specificcommunication, organization, andinformation exchange needs thatwere poorly supported.

Adapted Tools to Communica-tion Needs In this subsectionwe summarize some technicalaspects of communication toolsused during our experiment.A brief overview of communicationmodes are recalled, followed by asummary of the ICT used duringthe study. A short paragraph isthen dedicated to tools supportingvoice media, and finally, hardwareuse is discussed.

Fig. 9. Collaboratively designedplunger.

A Typology of CommunicationModes: As we have shown inprevious sections, informationexchanges may be classifieddepending on their content anduse:• Some are informal and concern

discussions which aim toexplain, to justify, and to clarifyconcepts.

• The others are formal, e.g.,constraints (the spring force atits high and low positions), data(a geometry with parameters,material properties), designrules, etc.

Information exchanges may alsobe separated from a time pointof view; as already mentioned(see also Table II), there are twocommunication modes:• Synchronous mode:

instantaneous exchangesbetween the actors; NetMeetingor Paltalk mainly use this mode.

• Asynchronous mode: thisallows to store the knowledge sothat it can be accessed at anytime by every actor; electronicmail and the discussion forumuse this mode.

ICT Use During Our Study: InternetCommunication Tools (see Table I)are the support of a virtualteam communication. Theymay be numerous usable tools

TABLE IIELECTRONIC MEDIA, DERIVEDFROM THE SPACE/TIME MATRIX

depending on type of meeting(synchronous/asynchronous)or information exchanged(formal/informal).

The communication supportswhich seemed to be complementaryfor our needs were used duringour study. They take into accountour various means of exchange(spoken, written, drawn) andmeans of reception (vocal andvisual). Our capacities to exchangeconcepts in suitable modes areimplemented in these tools.Indeed, a draft is very natural andefficient to describe a geometricalstructure, a text to clarify anequation or a vocal dialog to defineconcepts.

As the first experiment showed,with the forum as a communicationmedia, asynchronous mode maylead to very specific exchanges.Like email communications [5],forum media can be of leanrichness as it cannot containinstant feedback or visual cues.Despite this lack of richness,a forum owns other interestingproperties. Actually, asynchronousmedia allows information storageand asynchronous work report.So, in this experiment, the forumwas used as a storage site (like aPDM) for pre- and post-meetings,storing remarks, and saving keyelements. These elements maybe a mix of formal and informalcommunication (as the chatexample of Fig. 13).

However, the asynchronousmode is not sufficient; it leadsto a static design process andrequires synchronization of theparticipants.

For the synchronous exchangemode, NetMeeting and Paltalkwere used. The NetMeetingenvironment offers several tools:chat, whiteboard, applicationsharing, file exchange utilities,visual conference, and audioconference (but is restricted toonly two persons).

In our meetings, there were morethan two actors, so the visual and



audio possibilities of NetMeetingwere not sufficient. For our audioexchanges needs, Paltalk softwarewas preferred. It allows audio andvisual exchanges between severalpeople along with a chat. Foraudio exchanges, only one personcan speak at a time. The speakerlocks out phone access for allthe other actors when he speaks.This appeared to be of interest inexchange synchronization as willbe illustrated later.

In an earlier study [24] someauthors found that virtual teamlack of richness makes it unfitto do new product developments.We think that a virtual team, asproposed in this study, needssynchronous meetings for newproduct development. Thesesynchronous meetings werenecessary for our design goal asthey brought dynamics for groupcreativity and synchronization ofindividual works. Our exchangesduring such virtual meetings weresynchronous and mainly informal,due to the use of audio and visualmedia.

Communication Media for VoiceSupport: Various communicationmodes have been highlighted,some of them imposed by internetcommunication technologyrestrictions.

A speaker wishing a “turn taking”system to be able to presentinformation must use a tool suchas a chat. However, the visualtools (chat, whiteboard, etc.) arenumerous on the screen, and so,less powerful at holding humanattention. Activation of the hearingsense is easier because thisone is not disturbed by a lot ofinformation. For this reason, thefirst meeting did not reach theexpected goals. In meeting withvideo, turn taking is done by visualcues, but some studies showedthat without these visual cues,turn taking is completely different[25].

During the second experiment,Paltalk was used as substitutefor the vocal mode of NetMeeting.

By allowing a multispeaker modewith a controlled turn taking,undesirable group dynamics ofthe first meeting disappeared.This speech mode allowed goodeffectiveness during the thirdmeeting, which corresponded to aproject review. Indeed, under thecontrol of one of the speakers, themeeting allowed us to sketch outour work and to answer importantquestions.

In spite of the success of thisproject review, we wonder ifits effectiveness would remainvalid during a creating phase(brainstorming). Indeed, aproject review needs such astrict framework, for whichhand catching mode seems veryinteresting. But, what was an assetfor a project review can become aproblem where a dynamic dialogis necessary.

More flexible tools do exist, suchas “full duplex” technology, whereturn taking can seem moreanarchistic, but corresponding todynamic interactions and a highmedia richness. Depending on theinteraction between team membersfor creative phases, we may askcommunication specialists, “howcan communication technologybest support free and openinteractions?” [26].

Hardware: The codesignexperiments highlight someproblems due to the useof computer in support ofcommunication. ICT has moreor less the ability to answer ourproblems. It especially dependson which kind of informationand communication are carriedout. But it also depends on howperipheral hardware supports theinteraction with the ICT.

Software functionalities can becontrolled by means of commonperipherals such as mouse orkeyboard. Other peripherals maycome to fit between the actor andhis machine, to simulate naturalcommunications. If present-daycommunication tools only act viaour hearing and visual senses, the

years to come will see interestingnew interactions with forcefeedback hardware (haptic tools),like the ones used in distantmedical surgery.

We tested the means of simulatingthe presence of each participantthanks to webcams, allowingus to capture video flow and totransfer it to other members. Videocan be interesting to perceivereaction of the interlocutor, andgive a more natural feel (whichcan be useful when collaboratingdirectly with a client [9]). Thecontribution of video in our casemay prove a good support whenstudied objects are of real worldand are not exchangeable asdata-processing entities. Indeed,it seems interesting to be able tomake an experiment in real time,each participant being able tovisualize what is going on.

During the creative processesof codesign, one may have toquickly detail a concept, forwhich no support was prepared.Within this framework of codesign,the sketches or diagrams areparticularly adapted becausedesigners are accustomed to thistype of representation. This is whywe used a graphics table on whichthe drawing is very user-friendly,very similar to a pencil and asheet of paper. This peripheraldoes not bring new functionalities,but rather it supplements thedrawing by more accessibility andergonomics than the mouse device.Accessibility is a key point in sucha communication structure [26] forhardware or software.

ICT may carry out informalexchanges, but their use mustbe managed to ensure a bettercollaborative communicationprocess.

Adapted Tools to DifferentKinds of CollaborativeActivities Undoubtedly, allalong the collaborative designprocess, there are different periodswhere communications are moreor less intensive, involving avarying number of actors, and



leading to more or less interactionsand dynamics in the dialog, andto exchanges of more or lessstructured information. From ourexperiment, we asked ourselveswhich kind of ICT could best fitthe needs of each communicationcontext. With this in mind, we setup a basic typology of collaborativeactivities and tried to put aside aset of convenient communicationtools.

The “Brain Storming” TypeMeeting: This kind of meeting isnecessarily defined in a multipointmode of communication becauseexchanges are the heart of thisform of meeting. It essentiallyconsists in building one orseveral potential solution(s) to aproblem. Heavy calculations arenot welcome during this phase.People discuss informally andthen plan the actions to be takenin the form of tasks to carry out.With the result of this meeting,the attendees should have a clearidea of the continuations to give.The end of this meeting shouldthus lead to a list of tasks andinformation on the data useful toperform each of them.

The tools necessary for this typeof exchanges are typically toolsbeing very reactive and supportinginformal exchanges. One can thinkof full duplex multipoint discussionand sights sharing (vocal and videochannels). Notice that notproviding video sharing could bea positive thing in brainstormingmeetings as it might help people toexpress their ideas with less socialpressure [5]. But there can alsobe technical contents which wouldrather be supported by a sharedwhiteboard (for sketches, screenshots, pictures, or 3-D models,along with some annotations) anda chat (for more textual dialog,where chronology of exchanges isimportant). Another issue in thiscontext is to provide some supportfor the formalization of a report onthe meeting contents and results(for example, in terms of objectivesto be pursued). Of course, themeeting leader may write down

some points in real time, butthe ability of some ICT to storethe contents of the exchanges itsupported (whiteboard, chat, etc.)must also be used. Nevertheless,one difficulty may be to matchtime between different mediaso as to get the correspondencebetween a sketched proposal inthe whiteboard and arguments inthe chat contents, for example.

The “Project Review” TypeMeeting: This kind of meetingis also necessarily defined in amultipoint mode of communicationbecause it is structured toinform the other collaboratorsof the course of the project.However, speaking time shouldbe allocated to each major actorso that he presents his ownresults which must be reportsprepared in advance and shouldnot be built in the dynamicsof the meeting. Computationalsimulations or technical analysescannot be seriously consideredsimultaneously with this phaseof the meeting. Undoubtedly,mechanisms supportingannotations must make it possibleto write down the remarks of theother speakers. Each interventionin a review of the project aims topresent the problems encounteredby a specialist and his choicesimplying the community. Once theinterventions of the participantsare finished, an exchange musttake place allowing a proposal forcollective solutions. Exiting thisphase, the participants shouldknow the tasks they have to carryout.

Our experiments with this kind ofmeeting were a success becausethe unfolding of the exchangeswere controlled by someonecoordinating the meeting. Ourchoice of using a tool for oralexchange which does not supportfull-duplex (each speaker raiseshis hand and speaks when it is histurn) also had a very significanteffect on the global efficiency bykeeping people together and bycompelling them to listen carefullyto what the speaker was saying.

Often, one was having troublesunderstanding something in apresentation and tried to aska question. But he had to waitfor his turn to speak, and whilewaiting, he usually got his answer.By preventing the speaker frombeing interrupted, the meetingran smoothly. On the other hand,the required concentration madeit difficult to simultaneously takenotes that would allow making aneffective report and thus to havea clear documentation definingfurther phases of the project. Oraltools for dialog, text, or graph areindeed not memorized in the sameway.

One of the participants, such asthe leader of the presentation,should be in charge of writingdown a report like in classicalmeetings. Thus, the report writershould be provided with somespecific tools for this purpose. Butwe think that other participantsshould also be able to write downsome information because theycan be interested in specifictechnical information that is notrelevant to the others. The formof these tools is to be discussed.If it appeared obvious that theyshould support text and pictures(like screen shots), they perhapsshould also allow to record audioand video parts of the conferencethat are too rich to be summarizedduring the meeting.

The “Point-to-Point” Meeting: Thistype of meeting should allow fastinteraction between a relativelylimited number of participants(generally two) in order to beeffective. Following a projectreview, the participants agreed onprinciples of the solutions. Then,while revisiting the details of theirtasks, one of them discovers thathe missed information and that heneeds some explanation from oneof his colleagues. A point-to-pointmeeting seems well suited to thissynchronous collaborative phase.For example, these meetings arenecessary to specify the valuesof the data useful to each task.These data may be built as shared



concepts and parameters betweenthe involved engineers. As theseparameters are often relatedto ones available in dedicatedtechnical software, a usefultool would provide a networkconnection between these sharedconcepts and the related technicalparameters. This is one of theissues we propose in the finalsection of this paper.

One important and difficult pointin these three kinds of meetings(synchronous) is to providesupport for the formalization andcapitalization of the exchanges,so that results, technical choices,and shared concepts emergingfrom these meetings can beused simultaneously with futureasynchronous design steps.

Asynchronous Work: Of course,many tasks performed in anasynchronous mode are of greatimportance in the design project,and they need to be managedin a collaborative way. That is,important data exchanges mayoccur between the participants insuch a phase.

This way of working has beenwell known for a few yearsin most industrial contexts.Related ICT are mainly ProductData Management systemsused as technical informationrepositories, and forums forinformal asynchronous exchanges.Although we used a repositoryand a forum throughout ourexperiment, we did not intensivelystudy these points, because wedecided to focus on synchronouscommunications. However, akey point we propose is to keepconnected, even in asynchronouswork, with the other engineersby way of shared concepts andparameters constructed in thesynchronous mode, as defined in“point-to-point meetings.”

Adapted Tools to IntermediaryObjects Our experiments showthat some tasks of designhave a place in synchronousmeetings. Particularly, exchangesof equations, parameters with

their value, and meaning shouldbe formalized.

The aim of this experimentwas to establish formal linksbetween our shared knowledge.Informal communications betweenmechanical engineers andelectrical engineers lead to acommon mental representation.This common representationcan be exploited to formalizeobjects needed to the design of thestructure.

The discussion about the springis quite clear. Electrical engineersmodel the electromagnetic circuitwith their own skills but parts oftheir models are associated withmechanical equations. A solutionwould have been to mix theknowledge needed to design thespring with the knowledge usedto design electrical parts. Thismeans that the spring equationcan be parameterized enough tobe used with the electrical model.This solution seems better thanothers in the case of a simplespring equation, but quicklybecomes impractical: an electricalengineer cannot integrate thewhole knowledge of every skill.

Examples of ExchangedInformation: In the air gapproblem, not only drafts wereexchanged, but also somesimplified rules to explain choices.It seems that without them,solution delays happened. Forexample, the following rule can beapplied several times during thedesign:

“suppress, or if it is notpossible limit, the gap (e.g.,the air-gap) between each partof the magnetic circuit.”

Contrary to that, it is important forthe mechanical designer to knowthat the permanent magnet can beanywhere in the magnetic circuit,but mechanically it is difficult.So, depending to its placement,its shape, and its mechanicalstresses, it may be very differentin shape, and so its cost may beincreased or decreased. This is wellknown by the electrical designer

and is easily discovered by themechanical designer. In fact, thisis common sense enriched byexpert knowledge.

Designers must also coordinatetheir vocabulary (the clearance/airgap example). This corresponds todomain knowledge mapping. Suchknowledge has been transmittedby text in chats, in the forum, orby voiced discussion in the netmeeting.

As illustrated by the followingfigures (see Figs. 10–13), severalkinds of information can beexchanged in the interprofessionaldialog.

Schematic information was oftenused. This concerns:

Fig. 10. The principal figure (baseelement) for the dialog between theactors at the beginning of the designexperiment: an example of schematicinformation exchange.

Fig. 11. Examples of figures drawnby the actors on the whiteboard withtextual information and comments.

Fig. 12. Example of screen copiesout of CAD software as shared on thewhiteboard.



• the principle draft of thestructure (see Fig. 10);

• drafts and sketches drawn byhand and digitized by a scanneror directly drawn by the mean ofa graphic tablet (see Fig. 11);

• schemas, figures, or curves fromCAD or analysis tools.

For Fig. 12, screen copies haveoften been put in the forum orexchanged via the whiteboard.Nongraphical information has alsobeen exchanged:• values in tables, professional

rules (e.g., to define theexchange surface of themagnetic flux);

• equations with their semantics(see Fig. 13);

• parameters with their values,their units.

The Information Supports: Duringmeetings, informal exchangeslead to the creation of a sharedknowledge base. When bothelectrical and mechanicaldesigners execute more formalprocesses, such as the sizingprocess, they may also solve somemisunderstandings. These moreformal processes require highlyspecific knowledge of scientificdomains, which are hard to stateclearly in a few words, and rely ondedicated tools to model the entiredevice. Although the concepts ofeach domain may be discussedby informal means, this phaserequires more verbal exchangesbetween the participants. Theseexchanges are formal and needto be built dynamically. Thereis a need for a formalization ofthe concept of IO (intermediaryobjects) [15], [27].

A common database involvesseveral possible scenarios:

Fig. 13. Example of textualinformation exchange through chatwindow.

• In a first scenario, one mayuse simple ICT, that does notprovide support for formalizedIO. It leads to a nonoptimaldesign which must be improved.

• A second scenario woulduse dynamic exchanges offormalized IO between thedesigners. In the case ofthe discussion dealing withthe spring, constraints wereintroduced by the electricalengineers in their models afterconsultation with mechanicalengineers. One could imaginecreating a link between thedifferent actors providing themwith up-to-date informationabout the spring (dimension,equation, etc.). These new IOincrease the common model ofeach multidisciplinary designer.

• A third scenario considers aneutral designer in charge ofthe sizing. This designer mustintegrate enough knowledgefrom the different professions todo all the tasks alone. Moreover,every designer should be able toexplain its knowledge once andto integrate it into a stand-alonecontainer [19], [21]. In this way,every technical problem has tobe defined in a global knowledgebase, i.e., a product model. Theneutral designer has only toconsult this database to carryout the design. However, suchglobal knowledge base would behard to carry out.

Knowledge formalization is nota task to do once and for all,it is a highly dynamic process.The design process leads to thecreation of IO built with theexchanges between designersduring the process. The integrationof a formalized support for IOduring the design process to tryto answer encountered problemsshould be supported by dynamictools.

Communication tools are alsoinformation carriers. Theexchanges between speakersare mainly informal; they are usedto share ideas and to formalizeconcepts. When these concepts

are formalized, they have to beclarified continuously. However,ICT are not always adapted to sucha task.

During experiments, whenexchanges are abundant,interesting information maybe formalized in a textual way.For example, in our experiment,it has been carried out in thechat. At the end of the meeting,whiteboard and chat contentswere backed up. After the meeting,the speakers with questions orcomments put them into theforum. Several remarks can bemade about this procedure relatingto the re-exploitation of capitalizedinformation during the meetings.

The utilization of the datacreated during the meetings isrelatively complex. There is nolink between information thatappeared in various media, andit is hard to keep chronologicalconsistency across the differentcommunication tools. A tolerancingchain can indeed be expressed byan equation related to a diagram.However, the relation which wasimplicit during the meeting (thanksto the vocal support) does not existin the backup. It is difficult to findboth a temporal and relationallinks.

The practice of writing meetingreports comes mainly from thepaper medium on which one cannote successively the discusseditems. During cooperativemeetings, the significant numberof ICT does not allow participantsto take these necessary notes.Automatic mechanisms exist incentralized environments, suchas CoCreate, making it possibleto trace the actions carried outin the software. However, suchan automatic mechanism cannotact as a filter as humans dowhen writing down notes. Itseems necessary to formalizedecision-makings by drafting ofnotes during the meeting.

What Kind of Exchange Supportsfor Structured Information : Itappears from these collaborative



design experiments that thereare too few tools availablesupporting structured informationexchanges in synchronous modecollaboration. Thus, we point outthe need of such tools. They arededicated to support the dynamicdefinition and structuring of data,information, or knowledge [28] ina collaborative design context, andwe are looking for technologiesthat could support this.

New protocols are being developedto increase the internetcommunication possibilities.The XML (eXtensible MarkupLanguage) formalism and theassociated style sheets seem to bea good way to define, store, andexchange structured information.It is easy to understand andit offers numerous tools forautomatic treatments. Forexample, it may allow thesame piece of information tobe presented in a different wayaccording to the user’s choice andpoints of interest. Also, the recentdevelopment of standards such asCORBA (Common Object RequestBroker Architecture), DCOM(Distributed Common ObjectModel), and EJB (EnterpriseJava Bean), for distributedobjects and components, is

useful to create connectionsbetween professional applicationsthroughout heterogeneouscomputer sites and systems. Bycombining these technologies,it will be possible to developnew tools supporting dynamicstructured information exchanges.

New Collaborative ToolsProposal

Specification Sheet: Culturalissues appear during collaborativework whenever at least twodifferent skills are represented(electrical and mechanical inour case). Note that severalsubcategories of expertise maybe distinguished in both of thesetechnical fields. Both electricaland mechanical engineers worksimultaneously and must share theresults of their analyses. We haveseen in the study that mechanicaland electrical problems can appeartogether. It is quite impossible toenumerate every concept that theyneed to share. It mainly dependson the project context and mustbe defined dynamically. Therefore,one must provide the designerswith a framework designed tomanage synchronous meetingswhere concepts to be shared aredynamically defined. These toolsmust also support different levels

and organizations of information.By referring to the taxonomyproposed in [27], one can speakabout sharing and managing:• “data,” “information,” or

“knowledge”;• or from another point of view,

“structured,” “semistructured,”or “nonstructured information”;

• and a third classification mayconcern the “best” way ofexpressing the information:vocal, graphical (sketch,3D model. . .) [28], textual,mathematical, rules, tables.

Thus, the ideal communicationtool may support these differentkinds of exchanges and providedesigners with the ability to definesimple intermediary objects,or more complex objects as an“aggregation” of basic ones.

Framework Proposal: Let ussummarize now the framework ofthe new tools we are developingto support collaborative workin technical product design. Aschematic view of the collaborationsystem framework can be found inFig. 14.

Apart from tools dedicated todirect informal communication,such as chat, instant messengers,whiteboard, videoconference, or

Fig. 14. A schematic view of the collaboration framework.



application sharing, one mustprovide every person involved inthe design project with a GUI(graphical user interface) thatallows the construction of IO tobe shared with their colleagues.Then, connections with technicalsoftware are developed usingeach dedicated API (applicationprogramming interface): betweenthe shared objects and somefeatures or parameters in technicalsoftware, and between GUIand software. Among the latestgeneration of distributed objectsdevelopment tools, we have chosento manage shared information withthe CORBA protocol. In this way,a tool called CoDISS (CooperativeData & Information SharingSystem) has been developedto connect mechanical toolstogether. A system dedicated tostore and manage shared objects,called CoDVS (Cooperative DataVersioning System) has been alsodeveloped. The aim of CoDVSis archiving and versioning ofintermediary objects received fromtools which can be connected toCoDISS.

A first mockup of this kind ofsoftware connections has beenproposed in [29]. Note that moreinformation about the developmentproject of CoDISS and CoDVS canbe found in [30].

Further Work: The issue of newtools supporting collaborativedesign over the internet is clearlyto allow the emergence of acollaborative semantic community,a common project culture, orproject world.

Thus, with this in mind, and as amatter of research prospects, weneed to work on more preciselydefining the specification sheet ofthese tools.

First, we must take an interestin other technical fields orcultures that may be quitedifferent from mechanical andelectrical engineering, fieldswhere intermediary objects andknowledge cannot be formalizedin terms of CAD model, schema,

or equations, and where collectiveknowledge, action logic, or scale ofvalues are very different. This willbe done by getting in contact withseveral companies interested incollaborative design, for example inautomotive, or aeronautical fields.

Second, we must work togetherwith industrial sociologists andcommunication experts, to developnew skills in analyzing our furtherexperiments and getting concreteproposals out of them. How doesthe culture of the designers relateto their use of communicationmedia?

Finally, we must test othercommunication tools allowingmore dynamics in dialogs andinformal exchanges. This will allowthe analysis of full duplex vocalcommunication, with or withoutturn-taking, to check the interestof multipoints video, etc. What arethe effects of ICT tools on groupdynamics during a collaborativedesign?

Simultaneously, we will continuethe development of softwaremockup (CoDISS and CoDVS), tobe able to test, as soon as possiblein a real context, the new conceptswe propose and that do not existin present-day solutions.

CONCLUSION

This paper presents two differentcommunities with their ownspecific semantic fields anddomains which have been involvedin the collaborative design of atechnical product. Out of thisexperiment, we could extractsome analysis of professionalculture differences and confirmthe need of building a commonproject knowledge. Intermediaryobjects are being developed atthe interface between varioustechnical worlds or professionalcultures. Some analyses ofadapted communication toolsand organizations have also beenproposed to better match the goalsof various meeting contexts. Thetools supporting online creation ofthis intermediary information must

provide formalization facilities soas to increase data and informationexchange efficiency. This may alsoincrease the innovation ability ofthe company by providing moredynamics in communicationsbetween different actors involvedin the design process.

GLOSSARY

API: ApplicationProgrammingInterface.

CAD/CAM: Computer-aideddesign,computer-aidedmanufacturing.

CoDISS: Cooperative data andinformation sharingsystem.

CoDVS: Cooperative dataversioning system.

COBRA: Common ObjectRequest BrokerArchitecture

CSCW: Computer-supportedcollaborative work

DCOM: Distributed CommonObject Model

EJB: Enterprise Java BeanEMP: Electromechanical

plungerFTP: File-transfer protocol.GUI: Graphic user

interface.ICT: Internet

communicationtools.

IO: Intermediary objectsSCM: System (or software)

configurationmanagement.

XML: Extensible markuplanguage.

APPENDIX

The ElectromechanicalPlunger: The electromechanicalplunger (EMP) used to illustratethe paper is presented in [23].Such a system presents numerousphysical aspects: mechanical,magnetic, electrical, thermal. Thepower supply and the electroniccontrol are not considered here.

The goal of the plunger is to hitanother mechanism (a circuitbreaker) which is going to cut



an electrical circuit. In order toachieve this goal, a part called“striker” should move up and hitthe other system. The energy isgiven by a spring which is heldcompressed until the plungerreceives the order to release the“striker.” At its low position, thestriker is held down by magneticforce provided by a permanentmagnet. To release the spring,the magnet force is canceled byelectrically feeding a coil actingthroughout a magnetic circuit.Then the spring quickly releasesits energy, initiating the circuitbreaker mechanism.

Numerical requirements of thespecification sheet, needed toachieve the design, are as follows.

• Maximum bounding box in highposition: L = 30 mm�

Hmax = 40mm.

• Minimal percussion energy:0.12 J.

• Response time lower than 3.5ms.

• Residual force in high position:15 N.

• Holding in low position:withstanding an acceleration of2000 m � s�2.

• This product must be developedfor mass production at low cost.

In the design of such a system,several technical tools arerequired, inducing several kindsof information exchanges betweenthem.

In the following two subsections,we detail the tasks carried out by

the mechanical engineer and bythe electrical engineer.

Mechanical Engineer Tasks: In ourproject, the different mechanicalfields were represented by threeactors:

The designer deals with• making technological choices,• choosing materials,• defining the original shape and

thickness of the parts,• fitting and tolerancing,• performing kinematics

simulations (collision, speed,energy).

The structural engineer isconcerned with computationsand simulations in• mechanical strength (static and

dynamic),• deformation under load (elastic

or plastic behavior),• failure due to fatigue, buckling,

large strain,• vibration, modal analysis.

The manufacturing engineer dealswith• process planning,• choice of manufacturing

processes (machining, molding,stamping, welding. . .),

• simulations of specificprocesses,

• production cost estimation,• deflection of the part while

milling,• tools trajectory computation,• machining allowances.

Electrical Engineer Tasks: Theselected following tasks are often

done by the same electricalengineer [30], [32]:

• analysis of the plunger by finemodeling,

• macroscopic modeling for sizingprocesses,

• sizing process usingoptimization under constraints,[23],

• virtual prototyping to validateoptimized structure.

In these tasks, the designerdevelops several models, takingor not taking into account thedynamic phenomena of theplunger.

To carry out these modeling, theelectrical engineer uses severaltools such as

• mathematical tools to build itsanalytical models,

• optimization tools,• simulation tools for fine

modeling to validate theanalytical models developed foroptimization.

ACKNOWLEDGMENT

The authors would like tothank Loig Allain, for hiscontribution to the two firstNetMeeting experiments; Jean-LouBarbet, Yvan Pradourat, GregoryMarin-Pache and Thomas Vuillet,students in DESS CCI (JosephFourier University, Grenoble),for coding the first tools CoDVSand CoDISS; the IPI institutionfor its financial support, andparticularly Prof. Jan Ulijn for hisencouragement and guidance.

REFERENCES

[1] N. Shyamsundar and R. Gadh, “Internet-based collaborativeproduct design with assembly features and virtual design spaces,”Computer-Aided Des., vol. 33, pp. 637–651, 2001.

[2] J. M. Ulijn and J. B. Strother, “Communicating in business andtechnology: from psycholinguistic theory to international practice,”Peter Lang GmbH, Frankfurt, Germany.

[3] J. Ulijn and M. Weggeman, “Toward an innovation culture: What areits national, corporate, marketing and engineering aspects, someexperimental evidence,” in Handbook of Organizational Culture andClimate, C. Cooper, S. Cartwright, and C. Early, Eds. London, U.K.:Wiley, in press.



[4] C. W. Chee, G. L. Harrison, J. McKinnon, and A. Wu, “Culturalinfluences on informal, information sharing in chinese andanglo-american organizations: An exploratory study,” Accounting,Organiz. and Soc., vol. 24, no. 7, pp. 561–582, 1999.

[5] S. Kiesler and L. Sproull, “Group decision making and communicationtechnology,” Organiz., Behav. and Human Decision Processes, vol.52, pp. 96–123, 1992.

[6] S. Mer, “Les mondes et les outils de la conception, pour une approchesocio-technique de la conception de produit,” Ph.D. dissertation,INPG, Grenoble, France, 1998.

[7] L. Karpik, “Les politiques et les logiques d’action dans la grandeentreprise industrielle,” Sociologie du Travail, vol. 1, 1972.

[8] L. Boltanski and L. Thévenot, De la Justification, les Economies de laGrandeur. Paris, France: Ed. Gallimard, 1991.

[9] A. P. D. van Luxemburg, J. Ulijn, and N. Amare, “The contribution ofelectronic communication media to the design process: Communicativeand cultural implications,” IEEE Trans. Prof. Commun., vol. 45, pp.250–264, Dec. 2002.

[10] A. Xiao, H.-J. Choi, R. Kulkani, J. K. Allen, D. Rosen, and F.Mistree, “A web based distributed product realization environment,”in Proc. DETC’01, ASME 2001 Design Engineering TechnicalConf. and Computers and Information in Engineering Conf.,DETC2001/CIE-21 766, Pittsburgh, PA, Sept. 9–12.

[11] V. Riboulet, “Co-Conception par Internet,” in Mémoire de DEA 2001,INPG, Univ. Grenoble, France.

[12] M. Amiour, “Vers une Fédération de Composants Interopérables PourLes Environnements Centrés Procédés Logiciels,” Ph.D. dissertation,UJF-Grenoble I, Dept. Comput. Sci., Grenoble, France, June 17, 1999.

[13] B. S. Bell and S. W. J. Kozlowski, “A typology of virtual teams:Implications for effective leadership,” Group and Organiz. Manag.,vol. 27, no. 1, pp. 14–49, 2002.

[14] D. Xue and Y. Xu, “Web-based distributed system and databasemodeling for concurent design,” in Proc. DETC’01, ASME 2001Design Engineering Technical Conf. and Computers and Informationin Engineering Conf., DETC2001/CIE-21 287, Pittsburgh, PA, Sept.9–12, 2001.

[15] J.-F. Boujut and E. Blanco, “Intermediary objects as a means tofoster co-operation in engineering design,” in Proc. COOP’2000Conf.—Workshop 2; The Role of Objects in Design Cooperation:Communication Through Physical or Virtual Objects, Sophia-Antipolis,France, May 2000, pp. 11–22.

[16] D. Vinck and A. Jeantet, “Mediating and commissioning objects in thesociotechnical process of product design: A conceptual approach,” inManagement and New Technology: Designs, Networks and Strategies.ser. COST Social Sciences, D. M. Lean, P. Saviotti, and D. Vinck, Eds:European Commission, 1995, ISBN 2-87 263-144-5. COST A3.

[17] J. Estublier, Distributed Objects for Concurrent Engineering (LectureNotes in Computer Science). Berlin, Germany: Springer-Verlag, vol.1675. SCM9, Toulouse, France, Sept. 5–7, 1999.

[18] S. E. Poltrock and G. Engelbeck, “Requirements for a virtual collocationenvironment,” Information and Software Technology, vol. 1, no. 6, pp.331–340, 1999.

[19] M. R. Cutkosky, R. S. Engelmore, R. E. Fikes, M. R. Genesereth, T. R.Gruber, W. S. Mark, J. M. Tenenbaum, and J. C. Weber, “PACT: AnExperiment in Integrating Concurrent Engineering Systems,” IEEEComputer, vol. 26, no. 1, pp. 28–37, 1993.

[20] L. Roucoules and S. Tichkiewitch, “CODE: A cooperation designenvironment. A new generation of CAD systems,” Concurrent Eng. Res.and Applic., vol. 8, no. 4, pp. 264–280, 2000.

[21] L. Bannon and S. Bodker, “Constructing common informationspaces,” in Proc. 5th Europ. Conf. Computer Supported CooperativeWork. Amsterdam, The Netherlands: Kluwer Academic, 1997, pp.81–96.

[22] K. Schmidt and L. Bannon, “Taking CSCW seriously: Supportingarticulation work,” Computer Supported Cooperative Work, vol. 1,no. 1–2, pp. 7–40, 1992.



[23] E. Atienza, F. Wurtz, J. Bigeon, M. Perrault, and V. Mazauric, “Amethodology for the sizing and the optimization of an electromagneticrelease,” IEEE Trans. Magn., vol. 36, no. 4, pp. 1659–1663, 2000.

[24] A. Patti, J. Gilbert, and S. Hartman, “Physical co-location and thesuccess of new product development projects,” Eng. Manag. J., vol.9, no. 3, 1997.

[25] S. Whittaker, “Rethinking video as a technology for interpersonalcommunications: Theory and design implications,” Int. J.Human–Computer Studies, vol. 42, pp. 501–529, 1995.

[26] J. Carletta, A. Anderson, and R. McEwan, “The effects of multimediacommunication technology on noncollocated teams: A case study,”Ergonomics, vol. 43, no. 8, pp. 1237–1251, 2000.

[27] E. Blanco, O. Garro, D. Brissaud, and A. Jeantet, “Intermediaryobject in the context of distributed design CESA,” in ComputationalEngineering in Systems Applications. Lille, France: IEEE-SMC,July 1996.

[28] M. Gardoni and E. Blanco, “Taxonomy of information and capitalizationin a concurrent engineering context,” Proc. 7th ISPE Int. Conf.Concurrent Engineering (CE’2000), 2000.

[29] B. Belhabib, F. Wurtz, J. Bigeon, and E. Atienza, “An integratedplatform for electrical design,” in Proc. IEEE–IECON’99, San Jose, CA,Nov. 29–Dec. 3, 1999.

[30] V. Riboulet, B. Delinchant, L. Gerbaud, P. Marin, and F. Noël, “Toolsfor dynamic sharing of collaborative design information,” in RecentAdvances in Integrated Design and Manufacturing in MechanicalEngineering, G Gogu et al., Ed. Norwell, MA: Kluwer, 2002.

[31] B. Atienza, J. Bigeon, F. Wurtz, and V. Leconte, “EDEN: A genericintegrated component software for constraint optimization,” in Proc.13th Conf. Computation of Electromagnetic Fields (Compumag 2001),Evian, France, July 2–5, 2001, pp. 232–233.

[32] F. Wurtz, J. Bigeon, and C. Poirson, “A methodology and a tool for thecomputer aided design with constraints of electrical devices,” IEEETrans. Magn., vol. 32, no. 3, pp. 1429–1432, 1996.

Benoit Delinchant holds the degree Electrical Engineer (ENSIEG 2000) and is

preparing his Ph.D. at the Laboratoire d’Electrotechnique de Grenoble (LEG), France.

His primary research interest is the integrated design environment of electrical

systems.

Vincent Riboulet graduated from the École Normale Supérieure de Cachan (2001).

He is lecturer in mechanical engineering at the University Joseph Fourrier. He is a

Ph.D. student at the Laboratory 3S (Sols, Solides, Structures) in Grenoble, France,

where he focuses on codesign by internet.

Laurent Gerbaud holds the degrees of Electrical Engineer (ENSIEG, 1988) and

Ph.D. (1993) from the Institut National Polytechnique de Grenoble, France. He is a

researcher at the Laboratoire d’Electrotechnique de Grenoble (LEG), where he studies

the design process and tools of electrical systems.

Philippe Marin is associate professor in mechanical engineering at the ENSHMG.

He received his Ph.D. degree from INPG in 1995. He works at the Laboratory 3S

(Sols, Solides, Structures) in Grenoble, France, focusing on collaborative design

and manufacturing processes.



Frédéric Noël is associate professor in mechanical engineering at the Joseph Fourrier

University, Grenoble, France. He received his Ph.D. degree from INPG in 1994. He

works at the Laboratory 3S (Sols, Solides, Structures) in Grenoble, France, where he

focuses on finite elements simulation and collaborative design.

Frédéric Wurtz holds the degrees of Electrical Engineer (ENSIEG, 1993) and Ph.D.

(1996) from the Institut National Polytechnique de Grenoble. He is a researcher at the

Laboratoire d’Electrotechnique de Grenoble (LEG), where he works on the design

process and tools of electrical systems.


Documents

E-cooperative design among mechanical and electrical engineers: … › file › index › docid › 333844 › ... · 2020-05-26 · E-cooperative design among mechanical and electrical