Upload
mark
View
217
Download
0
Embed Size (px)
Citation preview
This article was downloaded by: [University of Connecticut]On: 11 October 2014, At: 02:44Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK
Architectural Engineering and Design ManagementPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/taem20
ICT-enabled Collaborative Working Environment forConcurrent Conceptual DesignDino Bouchlaghem a , Huiping Shang b , Chimay J. Anumba c , Mei Cen d , John Miles e & MarkTaylor fa Department of Civil and Building Engineering , Loughborough University , Loughborough,Leicestershire, LE11 3TU, UK Phone: +44 (0) 1509 223775 Fax: +44 (0) 1509 223775 E-mail:b Department of Civil and Building Engineering , Loughborough University , Loughborough,Leicestershire, LE11 3TU, UK Phone: +44 (0) 1509 228745 Fax: +44 (0) 1509 228745 E-mail:c Department of Civil and Building Engineering , Loughborough University , Loughborough,Leicestershire, LE11 3TU, UK Phone: +44 (0) 1509 222615 Fax: +44 (0) 1509 222615 E-mail:d School of Engineering, Cardiff University , Cardiff, CF10 3FQ, UK Phone: +44 (0) 2920875694 Fax: +44 (0) 2920 875694 E-mail:e School of Engineering, Cardiff University , Cardiff, CF10 3XQ, UK Phone: +44 (0) 2920875694 Fax: +44 (0) 2920 875694 E-mail:f School of Engineering, Cardiff University , Cardiff, CF10 3XQ, UK Phone: +44 (0) 2920874694 Fax: +44 (0) 2920 874694 E-mail:Published online: 06 Jun 2011.
To cite this article: Dino Bouchlaghem , Huiping Shang , Chimay J. Anumba , Mei Cen , John Miles & Mark Taylor (2005)ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design, Architectural Engineering and DesignManagement, 1:4, 261-280, DOI: 10.1080/17452007.2005.9684597
To link to this article: http://dx.doi.org/10.1080/17452007.2005.9684597
PLEASE SCROLL DOWN FOR ARTICLE
Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.
This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions
■ Keywords – Conceptual design; concurrent engineering;concurrent conceptual design; client/server architecture; Web-based systems
INTRODUCTIONThe architecture, engineering and construction (AEC)industry is noted for its fragmentation (Howard et al,1989; Anumba and Evbuomwan, 1996). For example, thedesign of a commercial building typically involves sixseparate major disciplines, in addition to the client, all ofwhom view the process from different perspectives andmay work for different companies. It is generallyaccepted that 80% of product costs are committed bydecisions made in the first 10% of the design process,so the greatest opportunity for economies occurs at
conceptual design stage. Also, getting it right first timesaves money, so conceptual design (CD) is important.
In recent years, concurrent engineering (CE) has beenregarded as an efficient approach to reduce AEC projectlead times and improve design quality. The manufacturingand electronics industries have implemented CE largelyby collocation but this is more difficult to achieve inthe AEC industry because of the high degree offragmentation. Moreover, current CE research in the AECindustry has been concentrated on the later stages of thedesign process and little work has been done on CD,although it is becoming increasingly recognized as beingimportant in the AEC industry because a good CD has thepotential to reduce AEC project lead times and overallcosts (Anumba and Newnham, 1998; Santoyridis et al,
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
261
AbstractEffective concurrent conceptual design (CCD) in the architecture, engineering and construction (AEC) industry isessential for reducing project lead times and improving the quality of the resulting design. Computer-aidedtechniques and tools are needed to facilitate concurrent engineering (CE) between geographically distributedproject team members during conceptual design (CD). This paper reports on a research project that has bothdesigned the system architecture and developed a Web-based CE tool to improve AEC projects during the CDstage. It describes the applications requirements for construction projects and presents a layered and integratedapproach for the integration of multidisciplinary perspectives in concurrent conceptual design. A prototypesystem (INTEGRA) has been developed to encapsulate this approach. Details of the overall system architectureand software components are included in the paper. The aim of the INTEGRA system is to develop IT-based CEtools that support AEC professionals’ collaborative work in a conducive and flexible way. The paper concludesthat CCD is an interesting and challenging area, and that many topics remain open for further investigation. Inparticular, there is a need to ensure the integration of legacy systems used by AEC professionals into newcollaborative design systems.
ARTICLE
ICT-enabled Collaborative WorkingEnvironment for Concurrent ConceptualDesignDino Bouchlaghem, Huiping Shang, Chimay J. Anumba, Mei Cen, John Miles
and Mark Taylor
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
1999; Anumba et al, 2000; Wang et al, 2002). It isrecognized that CD is very demanding and intellectuallychallenging. This is because, first, the functionalrequirements, operating constraints and evaluationcriteria during conceptual design are usually uncertain andincomplete and, second, CD issues in AEC projects ofteninvolve different professionals from different disciplinessuch as clients, architects, engineers and contractors. Thedecisions of all these participants interact with those ofthe other disciplines but due to the poor definition of thedesign, especially during the early stages of CD, theretends to be insufficient cooperation or coordination.Therefore, tools are needed to facilitate CE betweenremote participants, especially during the CD phase.
This paper reports on a research project that hasinvestigated the particular needs of concurrentconceptual design (CCD) – a challenging area thatrequires the development of novel techniques to dealwith designers’ needs to rapidly develop and assessideas. It presents the integration of multidisciplinaryperspectives in concurrent conceptual design(INTEGRA) system architecture and the development ofan advanced prototype IT tool for supporting CCD usingthe Internet as a communication medium. Given theavailable resources it has been necessary to restrict thescope of the INTEGRA project and the work has onlydealt with the CD of commercial, beam/slab-typebuildings such as a typical office or hotel.
RELATED WORKIT support for conceptual design has been an activeresearch area for some time. Recent examples includework on the synthesis and simulation of solutions formechanical engineering design problems (Yao andJohnson, 1997) and the Schemebuilder environment forMechatronics (Counsell et al, 1998). The latter uses aknowledge-based approach that has largely beendiscredited as an approach to CD. Both of these arelarge, sophisticated systems but they are not applicableto the AEC industry. For the latter, recent work onconceptual design includes the work of Mathews andRafiq (1995), Foley et al (1999), Khajehpour and Grierson(1999) and Miles et al (1999). None of the abovespecifically supports CE.
Although computer-supported co-operative workinghas been an active research area since the 1980s and
the techniques have been widely investigated forcertain aspects of concurrent engineering (CE) (e.g.Sriram et al, 1992; Cutcosky et al, 1993), there has beenrelatively little work to look at the particular needs of theAEC industry. Also, there has been very little work onthe particular needs of CE tools for CD where the abilityto rapidly develop and test ideas is vital. The AECindustry has some unique features that often rendertechniques developed for other areas of engineering, atbest, only partially applicable. For instance, the AECindustry is highly fragmented, almost all of the designsare bespoke, the client employs the services of thedesigners before what is to be designed is properlydefined and the resulting products are highly complexwith many more components than, for example, a car.
Different approaches for collaborative workingsoftware have been used for CD in the AEC industry;these include evolutionary computation, knowledge-based computer-aided design (CAD techniques), agenttechnology and Web-based concurrent design. CADsystems have focused on facilitating individual design inspecific domains or supporting the integration of severaldifferent knowledge-based CAD tools. The CAD systemdeveloped by Pohl and Myers (1997) is such an example.The system aids in developing schematic floor plansduring CD by horizontally integrating a CAD drawingenvironment with six knowledge-based systems thatspecialize in day lighting, sound control, structural systemselection, thermal behaviour, cost and spatial access. Thesystem serves as an interactive surface between thebuilding designer and the various intelligent design tools.Gero et al (1997) describe an integrated prototype-basedexpert CAD environment, which integrates CAD-basedbuilding design using prototype refinement with aknowledge-based system that verifies building codeconformance. However, despite the above work, it isgenerally accepted that CAD is too restrictive andcumbersome for CD (Bradley and Maropoulos, 1998).
There have also been a number of projects that haveused agent-based approaches to collaborative design.The ADLIB (Agent-Based Collaborative Design of LightIndustrial Buildings) project investigated the feasibilityof using intelligent agents as tools for collaborativedesign within the context of light industrial buildings.ADLIB focused on the potential for agents to suggestdesign alternatives and an appropriate devolution of
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
262 D. BOUCHLAGHEM ET AL
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
design responsibility between the designer and theagents (Ugwu et al, 1999).
For single-user systems, evolutionary computationapproaches to CD have been particularly successfulbecause they have the ability to search the space ofpossible design solutions. However, to date, thesesystems have suffered from limited geometricalreasoning abilities. For instance, all the systems forbuilding design (e.g. Mathews and Rafiq, 1995;Khajehpour and Grierson, 1999; Miles et al, 1999) havebeen limited to buildings with a rectangular floor plan,with the exception of the work of Shaw et al (2005). Thismore recent work does allow for more irregular shapes.
For Web-based collaborative design, Klein (1997)presents a system designed to improve the capture ofand access to preliminary and geometric designrationale within concurrent engineering teams. Theapproach supports the viewing and updating ofthe information by design team members through theintegration of CAD and World Wide Web technology.Design decisions and their rationale are stored in ashared database. These data are accessed and updatedby design team members using graphical user-interfaces on standard Web browsers. Preliminary (non-geometric) design decisions and the rationale areentered directly via the browsers. Geometric data aredefined via CAD systems and translated into 2D or 3Dformats. These images, after being entered into theshared design database, can be viewed over the Web.Huang et al (2001) proposed to establish a Web-basedframework that supports engineering changemanagement procedures and activities. The approachintends to provide better communication sharing,simultaneous data access and processing, and moreprompt communication and feedback.
Most of the work on AEC industry CE software hasconcentrated on the later stages of the design processand/or does not focus on configurable user-interfaces andthe provision of adequate mechanisms for version controland change management (Turk et al, 1997; Anumba andNewnham, 1998; Santoyridis et al, 1999). CD has specialneeds. The main work in this area is the intranet-basedwork of Fruchter et al (1993) and Fruchter (1996). Theapplicability of Fruchter’s work is limited by her use of aCAD system. As discussed above, CAD is acknowledgedas being too complex for CD. Also her work contains no
input from or evaluation by practising designers. Schmitt(1998) describes a number of systems for thecollaborative creation of graphic representations ofdesigns. The work is of interest but also does not involveany input from practising designers during thedevelopment and there has been very little evaluation,hence its relevance is questionable. The literature on ITsupport for design contains descriptions of manysystems that have not been subjected to the rigour ofpractical evaluation. The value of such work is debatable.
INTEGRA SYSTEM REQUIREMENTANALYSISThe approach used in the INTEGRA project was to workclosely with practising designers, contractors andclients. At the start of the project, an extensiverequirements capture process was undertaken toensure that the research team fully understood theprocesses involved in CD. The information gained wasthen used to determine the system architecture andsteer the remainder of the work.
Capturing the system requirements was conductedthrough a series of interviews with AEC professionalsusing knowledge elicitation (KE) techniques. The KEresults show that ‘actors’ on a typical building projectinclude a client, an architect, a structural engineer, amechanical and electrical (M&E) engineer and a contractor.A number of activities are identified by actors. Table 1gives an account of different actors’ roles and their majorfunctional characteristics established through the KE.
The main aim of the conceptual design team is toprovide the client with the plan layout, general form andstructural layout of the building. A typical CD process isillustrated in Figure 1.
● First, the client provides initial information such asthe client’s brief and geotechnical report to theteam members.
● The whole team discusses design issues andconstraints through project meetings.
● The architect studies the requirements of theclient’s brief and recent buildings of architecturalsignificance, proposes initial design options forcritique and comments from the other members,while the structural engineer presents initialstructural layout to the other members.
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 263
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
● Through a critical review, discussion andcommentary on the design options including planlayout and structural layout, the architect and thestructural engineer choose the most acceptablesolutions, and improve them until other membersare satisfied.
● The final design options will be presented in aformal plan layout, 3D image of design andstructural layout.
Note that one of the more surprising aspects of the KEis that the geotechnical engineer’s involvement comesbefore CD. This is because the major cost variant for anybuilding is the foundations. Hence the geotechnicalaspects of the design are approximately determined atthe stage when the land purchase is being negotiated.All subsequent foundation design, etc. at the CD stageis dealt with by the structural engineer.
LAYERED AND INTEGRATED SYSTEMARCHITECTUREBased on interview results and requirement analysis, theINTEGRA system has been designed using a layered andintegrated architecture. If construction information such
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
264 D. BOUCHLAGHEM ET AL
TABLE 1 Actor roles and their activitiesActors Activities Main ConcernClient Describe users’ requirements and functionality of the proposed building. Construction costs, construction time,
Supply client brief, track design decisions, analyse uncertainty potential profits and project risks
and risk minimization
Architect Leading designer. Form and functionality of the building
Provide alternative design options. Analyse context,
site condition, topography and client brief
Structural Scheme out options and decide which are the most Structure of the building. Column layout,
engineer suitable and present them to other roles. Produce a and column loads
sketch-based structural layout. Identify constraints of the project
M&E engineer Design of environmental conditioning of the building including Shape, orientation and lighting of the
all mechanical, electrical and public health services together with building. Floor-to-floor heights, cladding,
lighting, acoustics and building automation location of the lift shaft
Contractor Contribute ideas on build ability, risk and cost control Construction risk, cost, control strategy,
pitfalls, public utilities and ground
conditions
Project manager Manage the project. Management of the project
While there may be a single designated
project manager, s/he may be several actors that undertake
project management roles at various level and for various purposes
FIGURE 1 The conceptual design process
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
as building design brief files are to be accessed andused widely between clients, architects, engineers andconstruction managers, networking should beconsidered. Since the Internet is an internationalnetwork where geographically distributed people areable to exchange and communicate information, it canbe used to support multidisciplinary activities in theINTEGRA system. From the perspective of networkcommunication, the INTEGRA system is organized as aset of layered components. It has several layers orderedhierarchically from the most abstract (closest to thesystem problem domain) down to the most concrete(closest to the underlying hardware). The most abstractlayer is the user application layer and the most concretelayer is the hardware connection and support layer(Jacobson et al, 1998). On the other hand, activities suchas building constraint checking and risk assessmentcannot be performed within the communicationplatform; Web-based software needs to be developed toenhance the system functionality. From a systemsoftware design point of view, the INTEGRA system is anintegrated set of software components residing on thesystem physical model. The building blocks of thesystem are processes for designing subsystems,
packages, tasks and their interconnections. Therefore,the system can be viewed as both layered applicationsand a set of integrated functions.
LAYERED APPROACH TO THE INTEGRA SYSTEMA major function of the INTEGRA system is to providethe abstract tools required for transferring messagesand managing interactions across the Internet. Thesystem can be logically layered in terms of abstractionand designed as a series of vertical slices offunctionality that cut through all layers. A four-layerhierarchy has been used for the INTEGRA system andcontains a set of client/server relationships within thefollowing layers:
● user agent layer ● application process layer ● communication layer ● lower layer network service and support.
Each layer in the hierarchy uses the next lower layer andbecomes an abstract tool.
In Figure 2, the column on the left represents thesoftware layers used by the server, whereas the column
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 265
FIGURE 2 Layered INTEGRA system
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
on the right represents the layers used by the client. Thesoftware layers at the server and the client are thesame. Each layer has its interface called service accesspoints (SAPs) – a set of classes and objects that may beexternally accessed. The arrows in Figure 2 are thepaths traversed by messages and represent thedependency relationship, which indicates that softwarepackages in each layer depend on the tools belowthem. For example, a typical message originating in theapplication layer is passed down the left column of thefigure as it is prepared for transmission. Finally, it istransmitted by the lower layer at the server and receivedby the lower layer of the client. From there, themessage can be passed up the hierarchy until it reachesthe application layer on the client side.
The user agent layer houses the user agentcomponent that is an interface between the users, Webpages and Web applications. This componentimplements all functions that are typically associatedwith the graphical user interface (GUI). Since theInternet is used as a communication medium in thesystem, the user agent needs to have both Internet-oriented and multi-platform support. The user agent iseffectively a Java-enabled Web browser such asMicrosoft Internet Explorer or Netscape Communicator.The browser, together with its extensions and externalapplications, allows a user to navigate andcommunicate with the interface over the Internet.
The application process layer incorporates a Web-based application component that implements therequirements defined by the application within thecontext of the domain in which the applicationoperates. For example, a risk assessment applicationwill produce a variety of risk actions or initiatives basedon numeric input, fuzzy linguistic terms, calculationsand other considerations. It includes server applicationprocesses (APs) and client APs. In this case, theapplication software is partitioned so that somecomponents reside on the client side, while othersreside on the server side. Client APs may be scripts,add-ins, applets or external applications. Server APsmay be constructed using server-side technology suchas ASP (Active Server Pages), JSP (Java ServerPages)/Servlet, PHP (PHP Hypertext Processor,originally stood for Personal Home Page) or CGI(Common Gateway Interface).
The communication layer involves networkcommunication protocols used for the INTEGRA systembetween the client and the server. HTTP is anapplication layer protocol that directly supports Web-based INTEGRA system applications. SMTP is used totransfer mail. FTP supports the transfer of files betweenthe client and the server. HTTP, FTP and SMTP run over the TCP (Transfer Control Protocol)/IP (InternetProtocol).
The lower network service and support layer mainlyincludes the data link layer and physical layer, andnormally includes the device driver in the operatingsystem and corresponding network interface card in thecomputer. Together they handle all the hardware detailsof physically interfacing with the cable (or whatever typeof media is being used) (Stevens, 1994).
The layered approach to the INTEGRA systemmakes it possible to build each layer independently andlink them together when they are completed. The moreabstract layers are the clients that invoke the services ofthe more concrete layers. This one-way dependencymakes it possible to use the same lower-level serverlayers in different contexts because they do not dependon their clients. Similarly, since the lower layers offer awell-defined set of interfaces, they can be replaced withdifferent lower layers making the entire subsystemeasily portable to other physical environments.
INTEGRATED APPROACH TO THE INTEGRASYSTEMThe INTEGRA system has been implemented as an‘integrated’ environment, with multiple applicationsrolled into a single coherent system that is accessed viathe Internet. Its main software components areillustrated in Figure 3. They consist of eight functionalcomponents: (1) user interface, (2) client briefing tool,(3) cost modelling tool, (4) constraints checking tool, (5)risk assessment tool, (6) sketching and drawing tool, (7)3D visualization tool, and (8) synchronous andasynchronous communication tool. The user interfaceresides in the user agent layer; the client briefing, costmodelling, constraints checking, risk assessment,sketching and drawing, and 3D visualization tools aredistributed in the application process layer.Synchronous and asynchronous communication isimplemented in the communication layer.
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
266 D. BOUCHLAGHEM ET AL
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
User interfaceThe user-interface of the INTEGRA system is based onan HTML/XHTML presentation and includes a non-functional interface and a functional interface. The non-functional user-interface contains a description of theINTEGRA system such as contact information andsystem status. The functional user-interface containstool interface preferences and the corresponding front-end presentation interfaces for back-end toolapplications. Also, an alternative, 3D interface has beencreated as an attempt to develop a more intuitive styleof accessing what is a very complex environment. Fordetails of this, see Taylor et al (2004).
Client briefingThe client brief must be carefully formulated so as toprovide enough contextual information to ensure a solidfoundation for a construction project. In the INTEGRAsystem, the client brief contains the basic requirementsfor the building such as requirements for costs,gross/net areas, car parking, etc. The client briefing toolis designed to enable clients to input information on therequirements at the beginning of the project (Cen et al,2002). The software converts the bulk of the informationin the client brief into constraints which are then usedby the other tools in the environment.
Cost modellingThe cost model was the subject of extensivediscussions between the industrial participants and the
research team. Further advice was also sought from aspecialist cost consultant. At one stage, it was intendedto use a cost model that has emerged from backgroundresearch but, eventually, the industrial participantsswayed the decision in favour of a cost model that is ineveryday use and with which they were familiar. Thecost-modelling tool provides an element-based modelfor estimating the cost of a building design. Thereference prices for the elements can be obtained froma variety of publications and cost indices (Cen et al,2002).
Constraint checkingConstraints for a building design generally come fromthe client brief, Building Regulations and standards orthe design team members. The constraints can be ineither text or numerical formats. The constraintchecking tool within INTEGRA contains facilities forchecking the numerical constraints only. Generally, thetext-based constraints are too vague to be implementedin a computer system and instead they are kept in theconstraint checking tool and can be browsed asrequired.
The constraint checker was developed in the formof a Java applet that uses a graphical input. The need fora graphical format is because the designers have toprovide some sort of description of the design for thesystem to check. The graphical description is achievedvia an object-oriented sketching tool which allows thedesigners to develop a typical floor plan and add
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 267
FIGURE 3 Integrated INTEGRA system
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
features such as walls, cores, columns, windows,doors, standard rooms, etc. Each design disciplinemakes its particular contribution to the sketch. Althoughthe process sounds involved, in practice, the input onlytakes one or two minutes. To give the sketch validity anda scale, the tool uses a user-provided site plan to aknown scale as the background for the sketch and allitems in the sketch are then automatically added to thispredefined scale (Figure 4).
For the actual constraint checking, constraints suchas the gross area, net area and car parking are checkeddirectly from the sketch. Constraint checking of otherparameters such as project cost, floor-to-ceiling
heights, and building height, requires some additionaluser input (Cen et al, 2002). There is one additionalfeature in the constraint checker – a search algorithm.This is the routine that checks the building forcompliance with fire escape legislation by checking the travel distances to cores and/or fire escapes.Usually, this is a complex and time-consuming manual procedure which the checker undertakes inseconds.
Being able to define an outline design and thenquickly check it for constraint compliance is a hugeadvance on the present day manual techniques whereareas, volumes, etc. have to be calculated by hand for
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
268 D. BOUCHLAGHEM ET AL
FIGURE 4 The constraint checker
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
each design option. With the INTEGRA constraintchecker, each design option can be quickly defined andthen assessed for compliance.
Risk assessmentThe risk assessment tool elicits information from thedesign team regarding the risk associated with variousdesign options and other choices and then uses thesedata to rank project option risks using fuzzy logic. Thedecision is based on an aggregation of the project teammembers’ views. The value and validity of each teammember’s input is assessed in a confidential manner bythe other members of the team. So, for example, if adecision involved the structure, then one would expectthe team members to place the greatest emphasis onthe input of the structural engineer. This tool iscomposed of two parts – project server and projectclient. The whole risk assessment process is started onthe server side by the project manager. Team memberscan access the client system via the Internet. They getaccess to the necessary information and then submittheir inputs to the server. The tool processes them and
produces a rank-ordered list of risks that the teamneeds to address (Yang, 2001). Based on theirassessment, a final judgement is made. The process iscontrolled by one member of the design team who actsas a chair.
Sketching and drawingThe sketching and drawing tools are integrated withinthe Web interface with the aid of legacy systems. Thesesketching tools are for visualization purposes, asopposed to the constraint checking described above,and are used to assess the appearance of the building’selevation and how it fits into the surroundings. Theparticipants in the CCD can draw these sketches usingfour methods, depending on which they prefer –freehand sketching, Autodesk Architectural Desktop(ADT), Autodesk AutoSketch and Painter Classicsoftware (Figure 5). In addition, external hardware (e.g.WACOM Intuos Graphics Tablet System) is used torespond to user actions. The Intuos Graphics TabletSystem consists of two elements: a graphics tabletserves as drawing work area, and the Intuos pen, a
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 269
FIGURE 5 Sketching and drawing tool
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
pressure-sensitive freehand device is used for imageediting and creating. The WACOM control panel isdesigned to be customized and keep track of Intuostools settings. Different settings can be customized fordifferent applications.
3D visualization tool2D sketches and drawings can be turned into 3Dpanoramic views using this tool. It uses the MGIPhotovista software (MGI Software Corp, 2000) withinthe Web browser. Figure 6 shows the process ofconverting 2D sketches to 3D panoramic views.
Communication tools The communication tools are needed to facilitatecollaborative team interactions. These are based onNetMeeting (for synchronous communication) andBSCW (Basic Support for Cooperative Work) (forasynchronous communication) over the Internet.NetMeeting allows AEC professionals to exchangeinformation with each other and to collaborate onprojects. During meetings, they can jointly create andshare documents, without having the software on eachcomputer. Users can also communicate using text chat,audio and video; use the whiteboard for sharing
drawing/documents; transfer files; and access remotecomputers using Remote Desktop Sharing. The BSCWsystem enables collaboration over the Web (OrbiTeamSoftware GmbH, 2002). It is based on the notion of ashared workspace – a joint storage facility that maycontain various kinds of objects such as documents,tables, graphics, spreadsheets or links to relevant Webpages. A workspace can be set up and objects stored,managed, edited or downloaded with any Web browser.The BSCW system keeps members of a group informedabout each other’s relevant activities in a sharedworkspace.
The benefits of the integrated approach include:
● Smooth transfer of information (models,programmes, documents, data) from one tool toanother, for example, 2D sketches produced withsketching and drawing tools can be loaded into the3D visualization software to produce a 3Dpanorama. These 2D and 3D sketches can also beuploaded to the BSCW system.
● An increase in construction project control that isachieved through integration of multidisciplinaryperspectives in CCD, this integration leads to bettercommunication, planning, and monitoring.
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
270 D. BOUCHLAGHEM ET AL
FIGURE 6 From 2D drawing to 3D panorama
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
● Improved coordination among project teammembers through synchronous and asynchronouscommunication.
THE INTEGRA INTEGRATED PROTOTYPESYSTEMThe INTEGRA system prototype was developed toencapsulate the layered and integrated approaches. Ituses the Internet as a carrier, networkingmultidisciplinary team members using client/serverarchitecture. Multidisciplinary perspectives based on thedifferent roles in a construction project team such asclient, architect, and engineer are considered. Figure 7illustrates the structure of the current prototype system.The system software caters for a Web client/Webserver/application server/database structure. The Webclient can be located or installed on any computer overthe Internet. The client processes run concurrently onthe Web browser and interact with the Web serverthrough the HTTP. The Web server processes clientrequests, controls interaction between clientapplication and data, and returns the Web page to the
Web clients. The application server encapsulatesapplication-specific processing components. TheBSCW server is a legacy system used for documents,folders, URL sharing and accessing, while the FTPserver is used for uploading and downloading data files.The database server handles data-object intensivetasks.
CONCURRENT CLIENT PROCESSThe client processes are the Web browser and itsextensions including client-side scripts and Javaapplets. As collecting and validating users’ inputs is onefocus of the project, Java applets are used toaccomplish this requirement. For example, the clientbriefing, cost model and constraint checking tools areimplemented as Java applets. These particular tools areset up for asynchronous use by single users rather thanbeing truly collaborative. This is because allowing morethan one user to alter items at a given time can easilylead to confusion and conflicting operations on thesame design. If two or more users wish to collaboratein the usage of a particular tool, then this can be
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 271
FIGURE 7 INTEGRA prototype system
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
achieved by sharing a desktop using NetMeeting orsimilar software. The applets are used both assophisticated user-interface elements and forencapsulating the necessary construction logic. Figure 8shows two examples, these being the client briefingand cost modelling tools.
WEB/APPLICATION SERVERThe Web server provides the application supportrequired to respond to transactions andcommunications from clients. The prototype system
uses an Apache Web server that is responsible forinteractions involving the Web client, the applicationserver and the BSCW server. The application serverconsists of server-side applications that run on the Webserver. The current application server has beendeveloped as PHP applications for implementingbusiness rules, access control, workflow services andsession tracking. The application server softwarecomponents are illustrated below using the riskassessment tool.
Business rulesThe risk assessment process is a series of steps, shownin Table 2, that are encapsulated in the risk assessmenttool. For example, the CalContr.php in task 6 is tocompute contribution degree between the risks; itspseudo code is shown below:
Get risk items from the databaseGet relative weights of team members from thedatabaseGet contribution degree between the risks from thedatabaseCalculate contribution degree and select the used riskusing FSM
{Define the top level setDefine the bottom level setDefine the intermediate level setDefine the isolated level set
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
272 D. BOUCHLAGHEM ET AL
FIGURE 8 Client briefing and cost model
TABLE 2 Risk assessment processSTEPS TASKS ACTORS
Initialization Collect project information Project manager
Task 1 Generate risk issues Team members
Task 2 Gather and rationalize risks Project manager
Task 3 Assign weights to team Team members
members
Task 4 Derive absolute weights and Project manager
relative weights of team
members
Task 5 Input contribution degree Team members
between risks
Task 6 Determine selected risks using Project manager
fuzzy structural modelling (FSM)
Task 7 Assign risk probability and impact Team members
Task 8 Rank risks and input their actions Project manager
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
If (a risk locates the top level || a risk locates theisolated level)Put the risk to selected risk list}
Display contribution degree calculation formSubmit the form and invoke SaveUsedRisk.phpThe selected risks are stored to the database.
Access controlThe risk assessment tool provides role-based loginfunctions including the creation of team memberaccounts and the validation of login information. Theproject manager (PM) performs the initialization processwhich includes the input of project information, role listof team members and access rights. The information issaved in the database (Figure 7). The PM then notifiesthe team members of their user names and passwordsto login into the system. Only the team membersauthorized by the PM can use the tool.
Workflow servicesWorkflow control is another important requirement forthe tool, as the risk assessment process depends onteam members’ collaborative working over the Internet.Figure 9 shows the workflow process model, thesequence of activities performed by the team membersand the PM, and their interdependencies, where:
● Cnn – controls and automates the coordination ofthe workflow
● Taskn – corresponds to the specific processactivities for roles.
Each step defines a specific task and provides controlstructures for following activities. In the tool, stepn_flags
are saved in the database server and used to monitortask completion and sequence for each team member.
Session managementSince HTTP has no mechanism to maintain state,individual requests from the same team member are notrelated to one another. The Web server cannot easilydistinguish between team members, but maintainingmembers’ state is one of the fundamental requirements,for example, the tool needs to keep track of teammembers’ information to avoid external access andunauthorized data input. Thus, the session managementmechanism is implemented to enable risk data enteredby a member to be associated with that member over theperiod of use and to ensure that only membersauthenticated by the PM can use the tool. For example,steps 2, 4, 6 and 8 need to apply the following procedure:
if (!session_is_registered(‘VALID_ROLE’))You are not logged in, please go to login page......
if ($VALID_ROLE!=’project manager’)You are not Project Manager, you have no privilege todo this step......
BSCW SERVERThe BSCW server is an extension of the Web server,which means an HTTP demon that is extended by theBSCW functionality which is implemented as CGI scriptswith Python code. More details of BSCW can be seen atthe BSCW website http://bscw.gmd.de/. Currently, theINTEGRA prototype uses the BSCW server to establishsecurity and access rights of information, version andconfiguration management, and event notifications.BSCW provides the essential information exchange
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 273
FIGURE 9 Risk assessment workflow process model
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
infrastructure required for collaborative design. Thesefacilities allow the stakeholders to create and managethe various files that refer to a given scheme in a logicaland sensible manner.
Figure 10 shows the INTEGRA shared workspaceusing BSCW. This workspace is used to store differentkinds of information generated by application tools.Information is stored as objects arranged in a folderhierarchy including briefing files, sketches anddrawings, reports, etc. Team members can transferinformation from their machines to the workspace andset access rights to control the visibility of thisinformation or the operations that can be performed forothers (BSCW 4 Administrator Manual, 2002; BSCW 4User Manual, 2002).
Access rights The INTEGRA prototype environment makes use of theBSCW access rights model, which can define roles formembers and thereby assign differentiated accessrights to a shared workspace. Roles in the BSCW serverare ‘manager’, ‘owner’, ‘member’, ‘restricted member’and ‘registered user’. Role access rights in BSCW allow,
for example, that some users (manager, owner,member) may have complete control over an object in aworkspace whereas others (restricted member) haveonly read access or no access at all. Constructiondisciplines including project manager, client, architect,structural engineer, mechanical and electrical engineer,and contractor can be related to the predefined roles inBSCW. In the INTEGRA prototype, all disciplines shouldbe registered users and the project manager shouldalso be the workspace manager, which has R/W rightsto all objects.
● workspace manager, R/W, execute all actions + ● owner: R/W √● member: R/W *● restricted member: read-only Θ
Version management The INTEGRA information within a workspace can besubject to version control, which is particularly usefulfor joint construction document production. It also canprevent two people trying to check out and work on thesame design document simultaneously. INTEGRA users
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
274 D. BOUCHLAGHEM ET AL
FIGURE 10 INTEGRA shared workspace
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
can also set a lock to prevent the overwriting of adocument. The version state of a document indicates itsdegree of maturity or the pertinent stage in a workprocess. BSCW provides a menu with three versionstates – ‘experimental’, ‘stable’ and ‘released’ – whichcorrespond to the ‘transient’, ‘working’ and ‘released’ ofthe established versioning terminology (Santoyridis etal, 1999).
Event services The INTEGRA prototype makes use of BSCW eventservices to provide users with information on theactivities of other users, with respect to the objectswithin a shared workspace. Events are triggeredwhenever a user performs an action in a workspace,such as uploading a new document, downloading(‘reading’) an existing document, renaming a documentand so on. The system records the events and presentsthe recent events to each user.
FTP SERVERThe applet tools in the INTEGRA prototype use the FTPserver for temporary file storage. The code for the FTPfunction in Java called the Linlyn class is used toread/write files on the FTP server from the tool appletssuch as client briefing, cost modelling and constraintschecking in the INTEGRA system.
To upload a file: Linlyn ftp = new Linlyn (<servername>, <user>,<password>);ftp.upload (<directory>, <filename>, <contentsof file>);
To download a file: Linlyn ftp = new Linlyn (<servername>, <user>,<password>);String contents = ftp.download (<directory>,<filename>);
EXTERNAL APPLICATIONSThe sketching and drawing tool is a Web-basedapplication that connects proprietary systems such asADT, AutoSketch, Architecture, Painter Classic andPhotovista to the Web. The communication tool islaunched by the Web browser to provide additionalNetMeeting services. These proprietary systems are
integrated using WSH (Windows Script Host) inVBScript. For example, the following VBScriptstatements use WSH to run Photovista:
● Dim wshShell● Set wshShell = CreateObject(‘Wscript.Shell’)● wshShell.run ‘PVISTA’
DATA ACCESSThe database server MySQL is used to provide data-related services for the INTEGRA environment. Theseservices include storing and retrieving data, aggregatingresults from existing data (for example, summingvalues), updating or deleting data, organizing orreorganizing the logical structure of data andadministering the database management system. It canbridge the server-side applications and backenddatabase through database connectivity. In a dataaccess topology, a data engine would process requestssent from the client’s side of the system. The languageused in these requests is in a form of SQL (StructuredQuery Language).
SYSTEM EVALUATION Many forms of software are not amenable to testingand evaluation by using known solutions orexperimental results. In such circumstances, the onlyform of evaluation that is possible is to ask potentialusers to use the software in as realistic manner as canbe achieved and to pass an opinion on the suitability orotherwise of the software. It is recognized that theresults obtained from such an exercise are qualitativerather than quantitative but they are the only possibleindication of fitness for purpose. Also, when theevaluators are asked to test software which requiresthem to work in a way that breaks with their normalpractices, then the validity of the results becomes evenmore difficult to establish because unfamiliarity canproduce a negative response.
With the INTEGRA environment, it is not possible toevaluate it using, for example, closed form solutions andso it has been necessary to evaluate using potentialusers. Throughout the research process to create theenvironment, each stage was evaluated by the industrialparticipants so the resulting software would tend toreflect their views. Thus, to ensure that an independent
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 275
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
evaluation was obtained, it has been necessary toestablish another group of people to undertake this work.
The initial testing of the environment was undertakenby undergraduate and graduate engineering students.The main purpose of this work was to check that thesoftware worked as intended and to detect any majorbugs. At this stage, the environment was not completeso only parts of the system (mainly the constraintchecking, sketching and BSCW) were present. 12 peopleparticipated in this testing and as a result of this someminor modifications were made. Following the above,further rounds of testing were undertaken again usingstudents. Again the environment was not in its finalstate, but this work was used to assess the impact offurther additions to the software.
The main testing occurred at the end of thedevelopment process and in total involved 10 people,approximately half of whom were practising engineersand the other half graduate engineering students orengineering academics. The testing was based arounda workshop session which was divided into threestages. The first stage was an introduction to INTEGRAgiving an overview of the environment, its aims and theavailable tools. This was followed by a demonstration ofthe software. The third stage was a hands-on testingsession where the evaluators were encouraged to usethe system.
At the end of the above process, each evaluator wasgiven a questionnaire to obtain feedback on theiropinions of INTEGRA and their experience of using thesoftware. The majority of the questionnaire focused oneliciting information regarding the appropriateness orotherwise of INTEGRA for supporting CCD and teamcommunication.
SUPPORT FOR COMMUNICATION ANDCOLLABORATIONThe evaluators were asked to rate INTEGRA as asupport tool for AEC industry designers undertakingCCD. This opinion is based on the above limitedexposure.
The evaluators were asked a series of questions and the answers were typically given using a scale ofone to five, where 1 = strongly disagree, 2 = disagree,3 = neutral, 4 = agree and 5 = strongly agree. Inaddition, space was left for the evaluators to add furthercomments in free text. The first question sought forresponses ‘regarding the creation, storage and retrievalof documents’, this effectively being the parts controlledby BSCW. The majority of the evaluators agreed that theenvironment is effective in this area (Figure 11). Thesecond question looked at the ‘exchange of informationsuch as sketches and other documents’ and again theresponse was that it is effective.
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
276 D. BOUCHLAGHEM ET AL
FIGURE 11 The effectiveness of INTEGRA in terms of document handling, communication and collaboration
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
The third question elicited a more mixed set ofresponses, with the overall response being neutral. Thenext question was framed in the negative – ‘that theenvironment provides no support for achievingindividual and joint tasks and goals’. The evaluatorswere supportive of the software with the bulkdisagreeing with the question. The final question in thissection looked at the ‘usefulness of the system forfacilitating collaborative working’ and again theresponse was largely positive. Therefore, the overallresponse from this section was supportive.
SUPPORT FOR CCDThe next section in the questionnaire asks a series ofquestions about the software’s support for CCD. Thefirst question asks whether the evaluators ‘have beenprovided with all the technology that is needed tosupport CCD’ (Figure 12). The responses show thatthe evaluators were not entirely convinced about theeffectiveness of INTEGRA in this area althoughthe free text responses fail to give a reason why. Aquestion about the ‘user-friendliness of theenvironment’ obtained a more positive set of replies.The third question was again framed in the negativeand stated that the ‘environment was not efficient in
supporting CCD and would not contribute to thesuccess of a design project’. The result was stronglyagainst this suggestion. The final question looked atthe ‘overall integration of the tools within theenvironment’ and this obtained a positive response.Overall for this section, the questionnaire results weresupportive of INTEGRA.
THE PERFORMANCE OF THE ENVIRONMENTThis section of the questionnaire was derived by adifferent researcher who preferred to use a scale of 1 to 7 for the answers ranging from 1 = very poor to 7 = excellent. Again there were four questions in thesection and the results are given in Figure 13.
The questions in this section cover the ‘ability of thesoftware to increase team productivity, support theexecution of CD, reduce time on document managementand increase stakeholder satisfaction because ofextended information access’. None of the questions inthis section obtained a response lower than adequateand most of them were ‘good’ or ‘very good’ with some‘excellents’. This is an interesting finding. Some of thedifferences may be because the longer scale permitsmore considered responses but, even so, there doesseem to be a stronger response to these questions.
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 277
FIGURE 12 The effectiveness of INTEGRA for supporting CCD
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
THE INDIVIDUAL TOOLS AND TASKSThe evaluators were also given questions about theindividual tools with, as explained below, the exceptionof NetMeeting and the risk assessment. To ensure thatthey experienced all parts of the environment, theywere also required to complete a set of tasks such as‘drawing a typical floor plan’, ‘checking the plan forconstraint compliance’, ‘using the cost model’,‘creating an elevation and 3D view of the design’, etc.The full set of replies is too lengthy and complex to becovered here but the responses were all positive. Onlytwo questions received any replies that were mildlynegative and these were for the ‘creation of the 3Dview’, where two of the users rated this as less thanadequate, and for the ‘fire escape constraint checker’,which received less than adequate from one evaluator. However, another evaluator also rated this asexcellent!
The NetMeeting tool was not included in the aboveevaluation but was tested using the research teammembers. The tests included using text chat,whiteboard and audiovisual communication on anetwork where the slowest line speed is 10 mega bitsper second. The test involved six people trying tocommunicate simultaneously and, sadly, it was a failure.A limited amount of audio communication was possible
but the response was not consistent or reliable enoughfor everyday use. The visual communication was poor.The only thing that worked well was the text chat.Further tests were undertaken with smaller groups ofusers but even with just three users, the response timeswere poor and the visual communication, in particular,was very limited. It was concluded that without a muchhigher band width being available or the usage of farmore sophisticated tools such as VIC (http://vrvs.cern.ch/Doc/vic-guide.html) and RAT (http://www-mice.cs.ucl.ac.uk/multimedia/software/ rat/), thekind of communication that is required is not possible.
The evaluation of the risk assessment tool wasundertaken as a separate exercise because its usage isrelatively time consuming and it would have made themain assessment too lengthy. To evaluate this tool, arisk assessment scenario was created and a group offour people were then asked to participate in anevaluation session. The process was initiated by theproject manager who specified the project information.Three further project team members were then involvedin the risk assessment process – a client, an architectand an engineer. The tool collated the submission of thewhole team, integrated the specification, chose andranked the top five risks. The evaluators wereimpressed with the tool and felt it is a useful addition
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
278 D. BOUCHLAGHEM ET AL
FIGURE 13 Performance of the environment
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
to the normal decision-making processes that are usedin CD.
SUMMARY OF THE EVALUATIONThe results of the evaluation indicate that therequirements analysis and the subsequentdevelopment of a system architecture for INTEGRA hasbeen a success and that the environment representsthe basis for the development of a more completecommercial product to support CD. It is recognized thatthe evaluation procedure is not perfect and that thosedoing the evaluation only had limited exposure to thesystem but, given the restrictions that the commercialsector places on people releasing their time, this isabout all that can be achieved.
CONCLUSIONSTo meet the requirements of virtual teams inconstruction and CCD processes, the INTEGRAenvironment has been designed using a layered andintegrated approach. The approach used has beenbased on an extensive requirements analysis withpractising designers. This has then been used to guidethe development of the software and the format of theenvironment. The prototype environment is a usableimplementation of web-based IT tools that enable AECprofessionals to work collaboratively and concurrentlyeven though they are distributed in time and space. Anevaluation has indicated that this prototype is applicablefor distributed construction team collaborative work andin particular that it could make significant productivitysavings in the concurrent conceptual design process.
ACKNOWLEDGEMENTSThe research team would like to acknowledge thesupport of the Engineering and Physical SciencesResearch Council (EPSRC) and the contribution from theindustrial partners – High-Point Rendel, Ove Arup,Grosvenor Waterside (Cardiff Bay) plc, Dale KennedyPartnership, and Birse Construction Ltd.
AUTHOR CONTACT DETAILSDino Bouchlaghem: Department of Civil and Building
Engineering, Loughborough University, Loughborough, Leicestershire,
LE11 3TU, UK. Tel: +44 (0) 1509 223775, fax: +44 (0) 1509 223981,
e-mail: [email protected].
Huiping Shang: Department of Civil and Building Engineering,
Loughborough University, Loughborough, Leicestershire, LE11 3TU,
UK. Tel: +44 (0) 1509 228745, fax: +44 (0) 1509 223981,
e-mail: [email protected].
Chimay J. Anumba: Department of Civil and Building Engineering
Loughborough University, Loughborough, Leicestershire, LE11 3TU,
UK. Tel: +44 (0) 1509 222615, fax: +44 (0) 1509 223981,
e-mail: [email protected].
Mei Cen: School of Engineering, Cardiff University, Cardiff,
CF10 3FQ, UK. Tel: +44 (0) 2920 875694,
fax: +44 (0) 2920 874597, e-mail: [email protected].
John Miles: School of Engineering, Cardiff University, Cardiff,
CF10 3XQ, UK. Tel: +44 (0) 2920 875694,
fax: +44 (0) 2920 874597, e-mail: [email protected].
Mark Taylor: School of Engineering, Cardiff University, Cardiff,
CF10 3XQ, UK. Tel: +44 (0) 2920 874694,
fax: +44 (0) 2920 874597, e-mail: [email protected].
REFERENCESAnumba, C.J., Baldwin, A.N., Bouchlaghem, D., 2000, ‘Integrating concurrent
engineering concepts in a steelwork construction project’, in Concurrent
Engineering: Research and Applications, 8(3), 199–212.
Anumba, C.J. and Evbuomwan, N.F.O., 1996, ‘A concurrent engineering
process model for computer-integrated design and construction’, in B.
Kumar et al (eds.), IT in Civil and Structural Engineering Design, Edinburgh,
UK, Inverleith Spottiswood, 39–42.
Anumba, C.J. and Newnham, L.N., 1998, ‘Towards the use of distributed
artificial intelligence in collaborative building design’, in E.T. Miresco (ed.),
Proceedings of the 1st International Conference on New IT for Decision
Making in Civil Engineering, Montreal, Canada, October 1998, Montreal,
Ecole de technologie supérieure, 413–424.
Bradley, H.D. and Maropoulos, P.G., 1998, ‘A relation-based product model for
computer-supported early design assessment’, in Journal of Materials
Processing Technology, 76(1), 88–95.
BSCW 4 Administrator Manual, 2002, Germany, OrbiTeam Software
GmbH.
BSCW 4 User Manual, 2002, Germany, OrbiTeam Software GmbH.
Cen, M., Miles, J., Taylor, M., Bouchlaghem, D., Anumba, C.J., Chim, Y.M.,
2002, ‘Requirement capture for concurrent conceptual design’, in M.
Schnellenbach-Held and H. Denk (eds), Advances in Intelligent Computing
in Engineering, Proceedings of the 9th International EG-ICE Workshop,
Darmstadt, August 2002, Dusseldorf, VDI Verlag, 201–211.
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 279
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4
Conallen, J., 1999, Building Web Applications with UML, Boston,
Massachusetts, Addison Wesley.
Counsell, J., Porter, I. and Duffy, M., 1998, ‘SchemeBuilder: CACD for
mechanism motion control’, Proceedings of a Workshop on Power
Transmission and Motion Control, University of Bath.
Cutcosky, M.R., Englemore, R.S., Fikes, R.E., Genesereth, M.R., Gruber, T.R.,
Williams, M.S., Tenebaum, J.M. and Weber, J.C., (1993) ‘PACT: An
experiment in integrating concurrent engineering systems’, in Computer,
26(1), 28–37.
Foley, A., Miles, J.C. and Moore, C.J., 1999, ‘Innovative support for bridge
design’, in C. Gold (ed.), Concrete Communication Conference 1999, British
Concreter Association, Crowthorne, July, Crowthorne, UK, BCA, 355–366.
Fruchter, R., Clayton, M., Krawinkler, H., Kunz, J. and Teicholz, P., 1993,
‘Interdisciplinary communication of design critique in the conceptual design
stage’, in L. Cohn (ed.), V-ICCCBE, Proceedings of the fifth International
Conference on Computing in Civil and Building Engineering, Anaheim, CA,
June 1993, New York, American Society of Civil Engineers, 377–384.
Fruchter, R., 1996, ‘Interdisciplinary communication medium in support of
synchronous and asynchronous collaborative design’, in B. Kumar and A.
Retik (eds), Information Representation and Delivery in Civil and Structural
Engineering Design, Edinburgh, UK, Civil Comp Press, 21–28.
Gero, J.S., Balachandran, M.B. and Rosenman, M.A., 1997, ‘Intelligent
expert system and CAD systems for design verification’, in I.D. Tommelein
(ed), Expert Systems for Civil Engineers: Integration Issues, New York, ASCE.
Howard, H.C., Levitt, R.E., Paulson, B.C., Pohl, J.G. and Tatum, C.B., 1989,
‘Computer integration reducing fragmentation in the AEC industry’, in
Journal of Computing in Civil Engineering, ASCE, 3(1), 18–32.
Huang, G.Q., Yee, W.Y. and Mak, K.L., 2001, ‘Development of a Web-based
system for engineering change management’, in Robotics and Computer
Integrated Manufacturing, 17(3), 255–267.
Jacobson, I., Booch, G. and Rumbaugh, J., 1998, The Unified Software
Development Process, Reading, Massachusetts, Addison Wesley.
Khajehpour, S. and Grierson, D.E., 1999, ‘Filtering of pareto-optimal trade off
surfaces for building conceptual design’, in B. Topping and B. Kumar (eds),
Optimization and Control in Civil and Structural Engineering, Edinburgh, UK,
Civil Comp Press, 63–70.
Klein, M., 1997, ‘Capturing geometry rationale for collaborative design’, in
R. Reddy and F. Pena-Mora (eds), Proceedings of 6th IEEE Workshops on
Enabling Technologies: Infrastructure for Collaborative Enterprises, Cambridge,
MA, June 1997, Los Alamitos, California, IEEE Computer Society, 24–28.
Mathews, J.D. and Rafiq, M.Y., 1995, ‘Adaptive search to assist in the
conceptual design of concrete buildings’, in B.H.V. Topping (ed),
Developments in Neural Networks and Evolutionary Computing for Civil and
Structural Engineering, Edinburgh, UK, Civil Comp Press, 179–187.
MGI Software Corp, 2000, Photovista virtual tour reference manual.
Miles, J.C., Sisk, G. and Moore, C.J., 1999, ‘The conceptual design of
commercial buildings using a GA’, in B. Topping and B. Kumar (eds),
Optimization and Control in Civil and Structural Engineering, Edinburgh, UK,
Civil Comp Press, 17–24.
OrbiTeam Software GmbH, 2001, BSCW Version 4.0 User Manual.
Pohl, J. and Myers, L., 1997, ‘ICADS: an integrated knowledge-based CAD
system’, in I.D. Tommelein (ed.), Expert Systems for Civil Engineers:
Integration Issues, ASCE, New York.
Santoyridis, I., Carnduff, T.W., Gray, W.A. and Miles, J.C., 1999, ‘Assessing a
versioning system for collaborative engineering design with a bridge design
experiment’, in International Journal of Computer Integrated Design and
Construction, 1(1), 17–28.
Schmitt, G., 1998, ‘A new collaborative design environment for engineers and
architects’, in I. Smith (ed.), AI in Structural Engineering, Berlin Springer-
Verlag, 384–397.
Shaw, D.J., Miles, J.C. and Gray, W.A., 2005, ‘Conceptual design of
orthogonal commercial buildings’, in B.H.V. Topping (ed.), Proceedings of
the 8th International Conference on the Application of AI to Civil,
Structural and Environmental Engineering, Rome, August – September
2005, Stirling, UK, Civil Comp Press.
Sriram, R., Livezey, B.K. and Perkins, W.A., 1992, ‘A distributed shared
database system for concurrent engineering’, in 4th National Symposium
on Concurrent Engineering, CE and CALS conference, Washington DC, June
1992, Society for Computer Aided Engineering, 29–43.
Stevens, W.R., 1994, TCP/IP Illustrated, Volume 1: The Protocols, Reading,
Massachusetts, Addison Wesley.
Taylor, M., Miles, J.C., Bouchlaghem, N.M., Anumba, C.J., Cen, M. and Shang,
H., 2004, ‘VRML virtual worlds – an alternative to the desktop metaphor
for GUIs’, in K. Beucke et al (eds), 10th International Conference on
Computing in Civil and Building Engineering, Weimar, June 2004,
Proceedings on CD-rom, 8.
Turk, Z., Wasserfuhr, R., Katranuschkov, P., Amor, R., Hannus, M. and Scherer,
R.J., 1997, ‘Conceptual modelling of a concurrent engineering
environment’, in C.J. Anumba and N.F.O. Evbuomwan (eds), Concurrent
Engineering in Construction, London, Institution of Structural Engineers,
195–205.
Ugwu, O.O., Anumba, C.J., Newnham, L. and Thorpe, A., 1999, ‘Agent-based
collaborative design of constructed facilities’, in A. Borkowski (ed.),
Proceedings of the 6th EG-SEA-AI Workshop, Artificial Intelligence in
Structural Engineering, Wierzba, Poland, September 1999, Warsaw,
Wydawnicta naukowo techniczne, 199–208.
Wang, L., Shen, W., Xie, H., Neelamkavil, J. and Pardasani, A., 2002,
‘Collaborative conceptual design-state of the art and future trends’, in
Journal of Computer-aided Design, 34(13), 981–996.
Yang, H.M., 2001, ‘A Web-based collaborative decision-making system for
construction project teams using fuzzy logic’, PhD thesis, Loughborough
University.
Yao, Z. and Johnson, A.L., 1997, ‘On estimating the feasible solution space of
design’, in Computer-Aided Design, 29(9), 649–655.
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
280 D. BOUCHLAGHEM ET AL
Dow
nloa
ded
by [
Uni
vers
ity o
f C
onne
ctic
ut]
at 0
2:44
11
Oct
ober
201
4