eWork and eBusiness in Architecture, Engineering and Construction

eWORK AND eBUSINESS IN ARCHITECTURE, ENGINEERING AND CONSTRUCTION

PROCEEDINGS OF THE 5th EUROPEAN CONFERENCE ON PRODUCT AND PROCESS MODELLING IN THE BUILDING AND CONSTRUCTION INDUSTRY— ECPPM 2004, 8–10 SEPTEMBER 2004, ISTANBUL, TURKEY

eWork and eBusiness in Architecture, Engineering and Construction Edited by

Attila Dikbaş Istanbul Technical University, Turkey Raimar Scherer University of Technology, Dresden, Germany

A.A.BALKEMA PUBLISHERS LEIDEN/LONDON/NEW YORK/PHILADELPHIA/SINGAPORE

Copyright © 2004 Taylor & Francis Group plc, London, UK All rights reserved. No part of this publication or the information contained herein may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, by photocopying, recording or otherwise, without written prior permission from the publisher. Although all care is taken to ensure the integrity and quality of this publication and the information herein, no responsibility is assumed by the publishers nor the author for any damage to property or persons as a result of operation or use of this publication and/or the information contained herein. Published by: A.A.Balkema Publishers, a member of Taylor & Francis Group plc http://balkema.tandf.co.uk/ and http://www.tandf.co.uk/ This edition published in the Taylor & Francis e-Library, 2006. To purchase your own copy of this or any of Taylor & Francis or Routledge’s collection of thousands of eBooks please go to http://www.ebookstore.tandf.co.uk/. ISBN 0-203-02342-0 Master e-book ISBN

ISBN 04 1535 938 4 (Print Edition)

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Table of Contents Preface

xii

Organization

xv

Keynote papers The future forces of change for the construction sector—a global perspective R.Flanagan Vectors, visions and values P.S.Brandon Help wanted: project information officer T.M.Froese The next generation of eBusiness and eWork—what is needed for the systemic innovation? An executive summary of the EU supporting research and innovation. B.Salmelin

2 16 29 38

Product modelling technology Virtual building maintenance: enhancing building maintenance using 3D-GIS and 3D laser scanner (VR) technology V.Ahmed, Y.Arayici, A.Hamilton & G.Aouad Supporting standard data model mappings R.W.Amor Virtual building environments (VBE)—applying information modeling to buildings V.Bazjanac A persistence interface for versioned object models D.G.Beer, B.Firmenich, T.Richter & K.Beucke Semantic parameterized interpretation: a new software architecture for conceptual design systems A.Eir Harmonization of ISO 12006–2 and IFC—a necessary step towards interoperability A.Ekholm

41

50 58

73 92

108

A novel modelling approach for the exchange of CAD information in civil engineering B.Firmenich Integration of product models with document-based information T.M.Froese Aligning IFC with the emerging ISO10303 modular architecture. Can AEC community take advantages from it? R.Jardim-Gonçalves, K.Farinha & A.Steiger-Garcao Optimization of project processing in the steel construction domain E.Holtzhauer & H.Saal Location sensing for self-updating building models O.Icoglu & A.Mahdavi Modeling cast in place concrete construction alternatives with 4D CAD R.P.M.Jongeling, T.Olofsson & M.Emborg Pilot implementation of a requirements model A.Kiviniemi & M.Fischer A combined product-process model for building systems control A.Mahdavi FIDE: XML-based data model for the spanish AEC sector J.M.Molina & M.Martinez A framework for concurrent structure analysis in building industry A.Niggl, R.Romberg, E.Rank, R.-P Mundani & H.-J.Bungartz IFC supported distributed, dynamic & extensible construction products information models M.Nour & K.Beucke Product definition in collaborative building design and manufacturing environment H.Oumeziane, J.C.Bocquet & P.Deshayes Implementation of the ICT in the Slovenian AEC sector T.Pazlar, M.Dolenc & J.Duhovnik Adding sense to building modelling for code certification and advanced simulation I.A.Santos, F.Farinha, F.Hernández-Rodríguez & G.Bravo-Aranda Towards engineering on the grid Ž.Turk, M.Dolenc, J.Nabrzyski, P.Katranuschkov, E.Balaton, R.Balder & M.Hannus Managing long transactions in model server based collaboration M.Weise, P.Katranuschkov & R.J.Scherer A software generation process for user-centered dynamic building system models G.Zimmermann & A.Metzger Process modelling technology

123

136 144

155 167 178 191 206 222 233 249

261

270 284

296

311 326

Embedded commissioning for building design Ö.Akin, M.T.Turkaslan-Bulbul, I.Gursel, J.H.Garrett Jr, B.Akinci & H.Wang The development of a technical office organization structure for enhancing performance and productivity in fast track construction projects T.A.H.Barakat, A.R.J.Dainty & D.J.Edwards Innovative production planning system for bespoke precast concrete products V.Benjaoran, N.Dawood & R.Marasini Process and information flow in mass customisation of multi-story housing T.Olofsson, L.Stehn & E.Cassel-Engqvist RoadSim: an integrated simulation system for road construction management S.Castro & N.Dawood Connet Turkey—gateway to construction in Europe A.Dikbaş, S.Durusoy, H.Yaman, L.Tanaçan & E.Taş Modelling collaborative processes for Virtual Organisations in the building industry M.Keller, P.Katranuschkov & K.Menzel Process modelling in building engineering M.König, A.Klinger & V.Berkhahn Space competition on construction sites: assignment and quantification utilising 4D space planning tools Z.Mallasi & N.Dawood Project planning: a novel approach through a universal e-engineering Hub—a case study of seismic risk analysis G.Augenbroe, Z.Ren, C.J.Anumba, T.M.Hassan & M.Mangini A decision support model for material supply management for the construction industry J.Perdomo, W.Thabet & R.Badinelli Modeling processes and processing product model information based on Petri Nets U.Rueppel, U.F.Meissner & S.Greb A building material information system: BMIS—in the context of CONNET– Turkey project E.Taş, L.Tanaçan, H.Yaman & A.Dikbaş

343 358

371 384 395 408 417

432 447

463

480

495

507

Ontologies Managing changes in the AEC industry—how can ontologies help? Q.Y.Cai & F.F.Ng An ontology-driven approach for monitoring collaborative design knowledge Y-C.Lai & M.Carlsen Setting up the open semantic infrastructure for the construction sector in Europe—the FUNSIEC project C.Lima, B.Fiès, C.Ferreira da Silva & S.Barresi

518 528 540

Practical use of the semantic web: lessons learned and opportunities found R.V.Rees, W.V.Vegchel & F.Tolman Supporting ontology management through self-describing concepts T.E.El-Diraby

555 569

eWork and eBusiness An assessment methodology for eBusiness and eCommerce in the AEC sector A.Grilo, R.Maló & R.Jardim-Gonçalves The digital dormer—applying for building permits online J.P.van Leeuwen, A.J.Jessurun & E.de Wit An inquiry into building product information acquisition and processing A.Mahdavi, G.Suter, S.Häusler & S.Kernstock Usefulness and ease-of-use assessment of a project management tool for the construction industry B.Otjacques, G.Barrère, F.Feltz & M.Naaranoja Development and implementation of a functional architecture for an eengineering Hub in construction Z.Ren, C.J.Anumba, T.M.Hassan & G.Augenbroe Legal and contractual issues—are they considered in RTD achievments M.A.Shelbourn, T.M.Hassan & C.D.Carter Modeling of ERP system solutions for the construction industry M.O.Tatari, B-Y.Ryoo & M.J.Skibniewski Construction informatics themes in the framework 5 programme Ž.Turk

585 594 607 621

633

648 660 670

Collaborative working Virtual pools of resources eliminate idle or missing equipment in AEC companies G.Antoniadis & K.Menzel DIVERCITY: distributed virtual workspace for enhancing communication and collaboration within the construction industry Y.Arayici & G.Aouad Cooperation and product modelling systems S.Blokpoel, R.R.M.Jongeling & T.Olofsson Linking early design decisions across multiple disciplines R.Drogemuller, J.Crawford & S.Egan State of the art of the implementation of Information Management Systems in the construction industry in Spain N.Forcada, M.Casals & X.Roca Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork A.Gehre, P.Katranuschkov & R.J.Scherer

686

695

707 719 731

744

Virtual communities: design for collaboration and knowledge creation I.L.Kondratova & I.Goldfarb The design framework—a web environment for collaborative design in the building industry M.Huhn Collaborative work practices in Turkey, five case studies A.Sanal Architecture for collaborative business process management—enabling dynamic collaboration S.Zang, O.Adam, A.Hofer, C.Hammer, M.Jerrentrup & S.Leinenbach Comprehensive information exchange for the construction industry J.Díaz

761 771

780 793

807

Mobile computing Mapping site processes for the introduction of mobile IT S.L.Bowden, A.Dorr, A.Thorpe & C.J.Anumba Mobile field data entry for concrete quality control information I.L.Kondratova Issues of context sensitivity in mobile computing: restrictions and challenges in the construction sector K.Menzel, K.Eisenblätter & M.Keller A context based communication system for construction D.Rebolj, A.Magdič & N.Č.Babič MOBIKO—mobile cooperation in the construction industry based on wireless technology R.Steinmann

817 831 843

862 873

Knowledge management Support for requirement traceability in design computing: an integrated approach with building data modeling I.Özkaya & Ö.Akin Interlinking unstructured text information with model-based project data: an approach to product model based information mining S.-E.Schapke & R.J.Scherer Live capture and reuse of project knowledge in construction: a proposed strategy C.E.Udeaja, J.M.Kamara, P.M.Carrillo, C.J.Anumba, N.Bouchlaghem & H.Tan Development of product family structure for high-rise residential buildings using industry foundation classes T.Wallmark & M.M.Tseng

885

900

913 923

Construction site and project management Assistance to building construction coordination by images S.Kubicki, G.Halin & J.-C.Bignon Gesprecons: eSafety and risk prevention in the construction sector J.M.Molina, M.Martinez & I.García Intelligent Construction Sites (ICSs) T.Mills, Y.Jung & W.Thabet Organizational point of view for the use of information technology in construction projects P.Praper Virtual reality at the building site: investigating how the VR model is experienced and its practical applicability S.Woksepp, O.Tullberg & T.Olofsson Evaluating competitiveness in construction industry: an alternative frame A.Y.Toprakli, A.Dikbaş & Y.Sey

941 952 964 974

980

994

Seismic risk and environmental management Analyses of Izmit earthquake by means of remotely sensed data: a case study, Yalova city S.Kaya, F.Bektas, C.Goksel & E.Saroglu Do phased Environmental Management Systems actually benefit SMEs? L.L.Hopkinson & C.Snow Software based knowledge integration for seismic risk management R.Pellegrini & P.Salvaneschi Real-time earthquake prediction algorithms S.Radeva, R.J.Scherer & D.Radev

1004

1013 1021 1031

IT supported architectural design Hybrid approach to solve space planning problems in building services G.Bi & B.Medjdoub A computational architectural design approach based on fractals at early design phases Ö.Ediz & G.Çağdaş APSIS architectural plan layout generator by exhaustive search B.Kisacikoglu & G.Çağdaş Architectural parametric design and mass customization S Boer & K Oosterhuis

1042 1055

1063

1082

S.Boer & K.Oosterhuis A model for hierarchical floorplan geometries based on shape functions G.Zimmermann & G.Suter

1101

E-learning and education Parametric representation of functional building elements with reference to architectural education M.Aygün & İ.Çetiner Life long learning for improved product and process modeling support p.Christiansson E-learning with puzzle collages C-H.Lin, T-W.Chang, L-C.Yang & S-C.Chen

1115

Author index

1144

1119 1133

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Preface

The global community has stepped into the next revolutionary phase of the long-term evolution of the information society and is now facing a new challenging phenomenon: Ambient Intelligence—providing and getting the right information to the right people in the right configuration at the right time anywhere. Our business processes have started to change. New working methods are available and asked for; new forms of organizations have been proven to be efficient and effective—the vision of the previous decade have been conquering practice. Ambient intelligence is the final keystone for a breakthrough and the industry-wide business revolution, in particular for our one-of-a-kind multishareholder and hence very complex projects. Intelligent management of the right information has become the focus of research. Computing power is now available on the Web and basic technologies—like P2P, Grid, Agents and Web services—have been developed to ripeness by the informatics community for application in AEC/FM. Apply it to your benefit—this is the offer of the informatics community—and also the challenge. Making intelligence happen requires more than solely utilizing the basic technologies and computing power on the Web. It means algorithms, either numerical or reasoning ones and it means enhanced semantic data structures, in which the information and knowledge is integrated and can be retrieved on request—when and where and how desired. Intelligence does not mean merely powerful numerical algorithms for solving and simulating complex engineering systems—as understood in computational mechanics. In this context intelligence means autonomous problem specification, decision preparation for problem solving and to some extent even problem solving itself. Such systems, not necessarily located on one computer and eventually distributed throughout the Web, should be capable of recognizing, deciding, retrieving and providing any piece of information, not only explicitly stored data, and at the same time support the co-operation with the end-user to serve him/her intelligently and polite. Data structures and hence product and process modelling are as important as the respective algorithms to make this happen, in particular for recognising the context, which is the prerequisite for any autonomous action. Data structures, i.e. data schemata must inherit meanings, semantics must be more than an identifier. They have to encapsulate knowledge on the objects. This knowledge must be re-usable in a flexible way and provide for reasoning to interrelate it with knowledge on other objects and their status described by the object data in order to build up the current context. Recognizing the effective state and crystallizing

the particular problems and various actors in an instantaneous process we are able to finally provide the right and focused information. This makes ambient intelligence happen. Research on and building of ontologies besides product data models have increasingly been the focus of research activities in AEC/FM. However, do ontologies really replace product data models? Or if not, do they subsume them? It is neither of them. Ontologies extend product models adding a new functionality, namely carrying knowledge, which is simply another objective. The main objective of product models is the very generic representation of real world objects as well as their respective general relationships to form a generic object net from the singular units, the objects to model a very generic skeleton for any kind of application. Other extensions to the generic product model are already on the way. For instance, product models are favoured, being the anchor for project documents and structuring the document information space. Data and text mining methods are increasingly applied to identify the representative semantic items of the documents and mapping them to the semantics of the product model in order to interpret the meaning of the document, i.e. recognizing its information contents and further multiinterlinking it with the product model. Again, being accessible via a VR building environment, ambient intelligence makes document information tangible. The user is no longer required to search for the right document in order to get the right information, he only has to identify the building object in his VR model and the information system provides him with the right information at any place and any time. The power of the automatic selectiveness depends upon the capacity and power of the underlying contextsensitive system—and again context-sensitivity is first of all determined by logic reasoning on product and process models based ontologies. We can subsume generic product models and ontologies as well as any other knowledge-related extensions of product models to be intelligent product models. In recent years, the quality of product models has reached a level that allows for the design of reasoning systems to check architecture and engineering systems consistency as well as conformity with building codes and guidelines. The few existing and very successful examples have to be considered first attempts, looking at the great variety of reasoning methods provided by basic informatics—this new area has just been touched on. However, the results gained are more than promising. The consistency checking methods are an important pre-requisite for co-operative and concurrent working, namely the consistency problems arising from long-term transactions in complex data bases, as it is the case in our AEC/FM data bases. We have now the confidence that they can be handled, but practically sufficient solutions still need valuable research and development efforts to cope with the whole AEC/FM domain. In this context, the numerical and reasoning algorithms are utilised in a new, separate information process, namely the information configuration process, so that we can now distinguish among processes on three different levels. Besides modelling the tangible work processes such as the production, organizational as well as the planning and controlling processes, we have to consider the intangible communication processes supporting formal information management and information logistics as well as the configuration processes to determine e.g. the user’s information needs, critical notification events or the optimal configuration and presentation of the information. In the future our research efforts will more and more shift from basic product and tangible

process modelling to enhanced intelligent product modelling and information process modelling. In recent years, new business concepts and modelling techniques have been developed for the virtual enterprise that have demonstrated their proficiencies in several best practice cases. Again ambient intelligence and additionally mobile computing are expected to provide for a push to flexible adopt the formal business models in AEC/FM practice. It will be of utmost importance to the industry to extend these organisational models to efficient autonomous teamwork across enterprises anywhere and in any team. Flexible systems and automatic configuration methods are required to install immediately operable virtual teams within short lead times, that are supported by sound organization structures, team-focused information spaces and corresponding information logistics. Virtual enterprises will no longer be limited to strategic alliances providing interoperability on a corporate and/or product level, but will also be able to significantly reduce the management cost of true interenterprise collaboration on the team level. Focusing on a few selected but outstanding topics of today’s research on Product and Process Modelling the papers of the ECPPM 2004 draw a very good overview on the current state of the art in practice, emerging new business models as well as on the cutting edge technologies available for architecture, engineering and construction. It thus provides for solid fundament to explore the outlined possibilities of applying ambient intelligence in our domain. The Istanbul Technical University, Turkey has been selected to host the ECPPM in 2004. After holding the ECPPM 2002 in the former candidate state of Slovenia, the EAPPM therewith again takes a clear stand for integrating researchers from all over Europe and aligning the various activities in product and process modelling for a better future. Today, Turkey is potential new EU member state of great importance and an agile economy. Moreover, it is the bridge between Europe and Asia and it has been a melting pot of cultures for more than 3000 years. In Istanbul the ECPPM 2004 again introduces a new platform to share knowledge and transform it into an active, fimctional asset ready to be shared, integrated and traded. Latest research results and businesses applications in the areas of eWork and eBusiness, product and process modelling, collaborative working, mobile computing, knowledge management, ontology will enable research and industry organisation to develop new lines of services and usher in a new breed of research areas. The committees of ECPPM 2004 have selected the best papers and organized attractive sessions for their presentation. The number of abstracts submitted was again unusually high and their quality was remarkable. Numerous people have made conference and the proceedings possible. We thank the authors, the scientific committee members and the ITU Project Management Centre for their contribution, support and encouragement in compiling this book. Sincere gratitude to each and all of them. Attila Dikbaş and Raimar Scherer Istanbul and Dresden, June 2004 eWork and eBusiness in Architecture, Engineering and Construction—Dikba§ & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

ECPPM 2004 Organization

CONFERENCE CHAIR Attila Dikbaş, Istanbul Technical University, Turkey STEERING COMMITTEE Raimar Scherer, University of Technology Dresden, Germany Ziga Turk, University of Ljubljana, Slovenia Gülsün Sağlamer, Istanbul Technical University, Turkey Nüzhet Dalfes, Istanbul Technical University, Turkey Yildiz Sey, Istanbul Technical University, Turkey EDITORIAL BOARD Amor, R., University of Auckland, New Zealand Andersen, T., FMRI Consultant, Denmark Augenbroe, G., Georgia Institute of Technology, USA Bjoerk, B-C, Swedish School of Economics and Business Administration, Finland Böhms, M., TNO, Netherlands Cervenka, J., Cervenka Consulting, Czech Republic Christiansson, R, Aalborg University, Denmark Çağdaş, G., Istanbul Technical University, Turkey Dağ, H., Istanbul Technical University, Turkey Drogemuller, R., CSIRO, Australia Ekholm, A., Lund University, Sweden Fischer, M., Stanford University, USA Froese, T., University of British Columbia, Canada Fruchter, R., Stanford University, USA Giritli, H., Istanbul Technical University, Turkey Goncalves, R., Universidade Nova Lisboa, Portugal Haas, W., Haas+Partner Ingenieurges. mbH, Germany Kalay, Y., Berkeley University, USA Kanoğlu, A., Istanbul Technical University, Turkey Katranuschkov, R, TU Dresden, Germany Lemonnier, A., ADEI, Spain Menzel, K., TU Dresden, Germany Mitchell, J., Graphisoft, Hungary

Moore, L., University of Wales, EG-SEA-AI, UK Rezgui,Y., University of Salford, UK Sağlamer, A., Istanbul Technical University, Turkey Skibniewski, M., University of Purdue, USA Smith, L, Federal Inst. of Tech., IABSE WC6, Switzerland Steinmann, R., Nemetschek, Germany Thomas, K., Waterford Institute of Technology, Ireland Tzanev, D., University of Sofia, Bulgaria Baslo, M., Istanbul Technical University, Project Management Center Ergun, Z.N., Istanbul Technical University, Project Management Center PROGRAM COMMITTEE Amor, R., University of Auckland, New Zealand Andersen, T., FMRI Consultant, Denmark Anumba, C., Loughborough Uni., UK Augenbroe, G., Georgia Institute of Technology, USA Bjoerk, B-C., Swedish School of Economics and Business Administration, Finland Böhms, M., TNO, Netherlands Borkowski, A., Polish Acad. of Sciences, Poland Cervenka, J., Cervenka Consulting, Czech Republic Christiansson, P, Aalborg University, Denmark Coyne, R., University of Edinburg, UK Drogemuller, R., CSIRO, Australia Ekholm, A., Lund University, Sweden Fischer, M., Stanford University, USA Froese, T., University of British Columbia, Canada Fruchter, R., Stanford University, USA Garas, F., Consultant, UK Garrett, Jr., J., Carnegie Mellon University, USA Goncalves, R., Universidade Nova Lisboa, Portugal Gudnason, G., Icelandic Building Research, Iceland Haas, W., Haas+Partner Ingenieurges. mbH, Germany Hannus, M., VTT Technical Res. Centre of Finland Howard, R., Technical University of Denmark Juli, R., Obermayer Planen+Beraten, Germany Kalay, Y., Berkeley University, USA Katranuschkov, P, TU Dresden, Germany Llambrich, A., ADEI, Spain Lemonnier, A., ADEI, Spain Liebich, T., AEC3, IAI, Germany Mangini, M., Geodeco S.p.A., Italy Martinez, M., AIDICO Constr. Tech. Inst., Spain Mitchell, I, Graphisoft, Hungary Moore, L., University of Wales, EG-SEA-AI, UK Nolan, J., European Commission, Belgium Rezgui,Y., University of Salford, UK

Skibniewski, M., University of Purdue, USA Smith, L, Federal Inst. of Tech., IABSE WC6, Switzerland Sozen, Z., Istanbul Technical University, Turkey Steinmann, R., Nemetschek, Germany Storer, G., Consultant, UK Tzanev, D., University of Sofia, Bulgaria Vanier, D., National Research Council, Canady Winzenholler, J., Autodesk, Germany Wix, J., AEC3, IAI, UK Zarli, A., CSTB, France LOCAL ORGANISING COMMITTEE Akkoyun, I., ITU, Project Management Center Artan, D., ITU, Project Management Center Aslay, Z., ITU, Project Management Center Baslo, M, ITU, Project Management Center Çağdaş, G., ITU, Faculty of Architecture Çelik, Ç., ITU, Project Management Center Dağ, H., ITU, Informatics Institute Erdem, A., ITU, Faculty of Architecture Ergun, Z. N., ITU, Project Management Center Gökçe, Umut, ITU Project Management Center, TU Dresden Göksel, Ç., ITU, Faculty of Civil Engineering Ilter, T., ITU, Project Management Center Oraz, G., ITU, Faculty of Architecture Öney, E., ITU, Faculty of Architecture Sanal, A., ITU, Faculty of Architecture Taşli, R., ITU, Faculty of Civil Engineering Yaman, H., ITU, Faculty of Architecture

Keynote papers

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

The future forces of change for the construction sector—a global perspective Roger Flanagan The University of Reading, UK ABSTRACT: All organisations, whether they are engineering and design consultants, contractors, or manufacturers and suppliers in the construction sector, need a strategy to survive, grow and succeed in a rapidly changing world. This paper identifies nine drivers that are impacting construction organisations. These drivers emanate from political, environmental, technological, social and economic changes impacting the global economy. In facing change, there is a need to balance the internal juxtaposition of change and continuity. The error made by some organisations is that they see all the new technology and materials and feel it must be used as soon as possible. Stopping to develop a strategy is important; it provides the framework to implement a plan for the future whilst maintaining the goals and the direction of the organisation.

1 INTRODUCTION The challenge for all organisations is facing, managing and implementing change, whilst at the same time ensuring profitability and maintaining customer satisfaction. Construction organisations need to recognise today, the oppoijunities of tomorrow. Realism must prevail; construction is predominantly a local business using mainly local labour and complying with local requirements. The developed countries will have different needs to developing, and newly industrialised countries. For example, India’s need is to have an efficient industry that can provide work for the people, whereas in the USA, with its higher cost base, the need is to build efficiently by exploiting technology, more mechanisation, and off site pre-fabrication wherever possible. Our lives have been transformed by electronics and information technology but, most of all, by the processes of change itself. Knowledge has become pivotal and globalisation has changed the face of competition. Local issues will always be important, but construction sectors around the world are not immune from the global issues that impact upon the economy, demand for their services, and quality of life. Drivers can be defined as those forces that cannot be changed and are an inevitable result of development in the broadest sense. The drivers of change involve social, technological, economic, environmental and political trends. Many countries have undertaken futures studies and Foresight studies with the aim of identifying the drivers that will influence construction in the next 20 years. Studies from 10 developed countries (Australia, Canada, Finland, France, Germany, Ireland,

The future forces of change for the construction sector

3

Singapore, Sweden, UK and USA) were analysed, from which nine key drivers were identified for the purposes of this paper; it is possible to identify many more drivers. Each country is influenced by local needs and challenges, with different emphasis between the developed and developing world. However, organisations need to consider the drivers of change and ask: ‘How will the drivers affect our business in the future, are they a threat or an opportunity, how should we react to the challenge?’ 2 THE DRIVERS 1 Urbanisation, growth of cities, and transportation 2 Ageing population 3 Rapid technological and organisational change 4 Environmental and climate change 5 Shift from public to private 6 The knowledge economy and information overload 7 Technologies for tomorrow 8 People, safety and health 9 Vulnerability, security, corruption and crime 2.1 Urbanisation The move from rural to urban communities, and the change from agricultural to industrial societies in all parts of the world is putting pressure on infrastructure and changing patterns of settlement. Between 1990 and 2025 the number of people living in urban areas is projected to double to more than 5 billion (UN, 1996). In 1800, only 2% of the world’s population was urbanised; this rose to over 30% in 1950, and 47% in 2000; a population that was growing three times faster than the population as a whole. Figure 1 shows that the percentage of urbanisation is predicted to be over 60% by 2030. Growing urbanisation creates congestion, puts pressure on utilities, and results in many social issues. In many cities built since the Industrial Revolution there is a decaying infrastructure that is not meeting increased demand. By 1900 only 12 cities had 1 million or more inhabitants, by 1950, this had grown to 83 cities. In 2004, there are over 410 cities with over 1 million people (UN). The current stock of infrastructure cannot cope, and modification, modernisation and refurbishment will be required to the existing infrastructure, with particular emphasis on the environmental impact. This dilemma is typical of many countries around the world.

eWork and eBusisness in architecture, engineering and construction

4

Figure 1. The growth of urbanisation (The Population Institute, 2004). People are more mobile, using roads, rail and air more frequently. In the UK, the average person travelled 5 miles per day in 1950, and 28 miles in 2001. Projections suggest this could reach 60 miles a day by 2025 (Cabinet Office, 2001). New airport development is fraught with social and environmental problems as airport development increases urbanisation, putting pressure on available land. Increased airport capacity will involve new regional airports with technology to cope with noise levels.

The future forces of change for the construction sector

5

2.1.1 Growth of cities Congestion is an increasing problem in urban areas, impacting the economy and the environment. European research showed that congestion costs between 1–2% of GDP (Cabinet Office, 2001). New methods of car parking will be required on streets and in car parks. Automatic (electro-mechanical) parking without manual assistance is being used in congested city centres, based on an underground silo system making maximum use of limited space (Trevipark, 2004). 2.1.2 Transportation Modernisation and retrofit is required for existing transport infrastructure. Engineers will retrofit roads with new technologies rather than reconstruct them; interactive vehicle-road systems will be widespread. Underground road construction will be inevitable as cities become more crowded. According to one report, it is anticipated that 10% of the trunk road network in the UK will be tunnelled by 2050. However, the report highlights the cost of tunnel maintenance—about 10 times that of an equivalent surface road. Restricting tunnels to cars and lighter vehicles can improve operation and reduce construction cost by around 40%. (RAC Foundation, 2002). This trend is also evident, for example in Sweden, the Gota Tunnel, and the ‘Big Dig’ in Boston. Tunnelling must be seen in the future as a viable option if all social and environmental costs are included. Light rail systems and people movers will be used increasingly in urban areas. Rail infrastructure is in need of renewal and improvement to take account of high speeds, greater density of use, improved safety measures and modernisation of control systems. Maglev (magnetically levitated) trains, that allow speeds of up to 350 km per hour, have experienced a long period of research, but development and application is now proceeding. For example, China is considering 250 km of rail extensions north and south of Shanghai using a maglev system. Greater demand management is needed including price tolling and inter-modality, maintenance planning and durability. Advanced transport telematics (ATT), will become prevalent, specifically concerned with improving safety and efficiency in all forms of transport and reducing damage to the environment. ATT allows efficient management and improvements in many areas of road transportation, such as demand management and automatic debiting, driver information and guidance, pedestrian and vehicle safety; monitoring of vehicle emissions; trip planning; integrated urban traffic control; public transport; and freight transport. 2.2 Ageing population The developed world has an ageing population whilst populations are getting younger in the developing world. According to the United Nations, the number of persons aged 60 years or older was estimated to be nearly 600 million in 2000 and is projected to grow to almost 2 billion by 2050, at which time the population of older persons will be larger than the population of children (0–14 years) for the first time in human history (UN, 2004).

eWork and eBusisness in architecture, engineering and construction

6

The majority of the world’s older persons reside in Asia (53%) while Europe has the next largest share (25%). Figures 2 and 3 show the percentage of population over 60 in different countries across the world.

Figure 2. Percentage of population over 60–2002 (UN, 2004).

Figure 3. Percentage of population over 60–2050 (UN, 2004). One of every 10 persons is now aged 60 years or older; by 2050, the United Nations projects that 1 person of every 5 and, by 2150, 1 of every 3 will be aged 60 years or older. The percentage is much higher in the more developed than in the less developed

The future forces of change for the construction sector

7

regions, but the pace of ageing in developing countries is more rapid, and their transition from a young to an old age structure will be more compressed in time. Few facilities are built to cope with an ageing population, so infrastructure will need to be built for an inclusive population and to meet a growing need for more healthcare facilities. An increasing number of people with severe disabilities are living longer and wanting to live independently. Design companies and construction organisations will need to think and work differently to meet this demand. 2.3 Rapid technological and organisational change The new kind of economy will create many more business opportunities, the rate of change will make it more difficult for an organisation to profit from an investment before a new competitor or development erodes the temporary competitive advantage. We are more used to the idea of firms seeking an environment in which they can put down roots and flourish, than to the idea of firms being created for an intentionally brief life to exploit an idea before being washed away by a new wave of innovation (Chatham House Forum, 1998). Technology enables almost anything to be done; deciding what to do becomes the critical skill. In the broadest sense of technology, our capacity to perform tasks, and our ability to perceive and interact with complicated, remote, huge or tiny, abstract or concrete things will be unprecedented. Personal computers will not be the main source of information. Instead of buying a computer, most people will buy devices with computers in them (embedded systems): those devices will talk to each other (interoperability). The big breakthrough will come when all communication technologies become integrated. Then you will have an all-in-one device that communicates. Agile, knowledge-deploying firms may be able to build sustainable positions in the new environment, but they will do so in an innovative way. The electronics industry talks of ‘copetition’—co-operation merged with frenzied competition. In design consultancy businesses, the high cost of developing the integration of CAD and visualisation will mean that development and application costs will be shared between competitors. 2.4 Environmental and climate change There is an increasing environmental awareness by governments, industry, clients and the general public. Global environmental problems are high on political agendas with increasing environmental legislation at a national, supranational and international level. Ozone depletion, pollution, depletion of resources, and global warming are all common topics of concern. Climate change will affect physical and biological systems in many parts of the world. The earth’s climate is predicted to change because human activities are altering the chemical composition of the atmosphere through the build-up of greenhouse gases— primarily carbon dioxide, methane, and nitrous oxide. The heat-trapping property of these gases is undisputed. Although uncertainty exists about exactly how earth’s climate responds to these gases, global temperatures are rising. A change in a regional climate could alter forests, crop yields, and water supplies. Flooding of settlements near low-lying coastal areas and rivers will be prevalent causing

eWork and eBusisness in architecture, engineering and construction

8

severe damage to buildings and infrastructure and putting greater pressure on the repair and maintenance sector of the industry. Energy demand is expected to increase for space cooling and decrease of space heating, according to location. Energy supply may be disrupted in the same way as other infrastructure. 2.5 Shift from public to private There is an increasing trend towards private funding of public infrastructure. Infrastructure projects such as power, telecommunications water and sewerage, and transport facilities have a number of characteristics: they lack portability, are rarely convertible to other uses, and investments in them are difficult to reverse. Infrastructure projects require very large capital investments, and have long development and payback periods. There has been a change in the forms of financing over the last few decades with a shift from public to private sector financing. For example, the UK government implemented a Private Finance Initiative (PFI) and there has been a major privatisation of utilities companies. The number of BOT, BOOT, BOO, and public/private partnerships has increased. The ‘public good’ nature of infrastructure projects makes them sensitive to public opinion and political pressure. The mechanisms to attract private finance into infrastructure provision are becoming more complex and more acceptable with the multilateral development agencies and institutional investors embracing the BOT concept. The message for construction is that there is no shortage of projects around the world, there is a shortage of bankable projects. This new form of procurement will grow in size, importance, and complexity. Ways will have to be found for large companies and SMEs to meet the challenges of the shift from public to private. 2.6 The knowledge economy and information overload The know-how of people is one of the critical determinants of competitiveness, both at a company and national level. Rapid technological changes mean that the traditional skill bases are no longer enough and the future will be characterised by skill shortages and skill gaps. High obsolescence of knowledge will have to be tackled in the context of an increasingly ageing workforce. There will be at least 1 billion university graduates in 2020 compared with a few million in 1920. There will be several billion more sophisticated customers by 2020, who will be better informed and more demanding than ever before. (Chatham House Forum, 1998) Learning matters, for individuals, companies, industry and the economy as a whole. The tradition has been to measure success by economic growth and by the level of capital. In today’s knowledge economy, knowledge capital is more important. Knowledge capital is ‘the source of economic value added by the organization, over and above the return on its financial assets’ (Strassman, 1998). Investment in education and training helps form the human capital—‘the knowledge, skills, competencies, and attributes embodied in individuals that facilitate the creation of personal, social, and economic well-being’ (OECD, 2001)—that is a vital element in assuring economic growth and individual advancement and reducing inequality.

The future forces of change for the construction sector

9

Technology gives us more and more access to information, so life gets more and more chaotic. ‘Information chaos’ prevails and we need to help people find the information that they want, when they want it. 2.7 Technologies for tomorrow Technology is a word that frightens some, excites others and prompts a feeling of inevitability in the rest. There have been major advances in materials and technologies in general. Extensive research has been undertaken into the use of composite materials, providing lightweight, strong materials that do not rely on the earth’s non-renewable resources. For example, soya and castor seed oils that are cheaper, bio-degradable and an economic multiplier of using local products (ACRES, 2002). Many of the new/smart materials are finding their way into the construction sector, having been first developed for other industries such as automotive, aeronautic and defence. These new materials, combined with the incorporation of intelligence, herald exciting scientific advances. Smart or intelligent materials or structures are those that recognise their environment and any changes and can adapt to meet those changes. System integration, mass and energy reduction are just some of the benefits of using smart materials. The technology of intelligent or ‘smart’ materials uses the knowledge of a number of different technologies such as materials science, biotechnology, biomimetics, nanotechnology, molecular electronics, neural networks and artificial intelligence. Four new technologies are considered in this paper: 1 Biomimetics 2 Smart materials and structures 3 Nanotechnology 4 Embedded intelligence—the application of information and communication technologies. 2.7.1 Biomimetics Biomimetics has been defined as ‘the abstraction of good design from nature’. This relatively new science advocates a radical approach of copying nature—biomimicry. Biomimetics needs the collaboration of the scientist and the engineer. The biologist understands the organisms and systems within nature whilst the engineer looks at the design, the strength and durability characteristics. Nature has already produced ‘smart’ materials, ones that interact with their environment, responding to changes in a number of ways. For example, plants have the ability to respond to changes in temperature, sunlight etc. in order to make maximum use of their environment. The feathers of a penguin are perfectly designed to be light but able to keep the bird warm in sub-zero temperatures. Imagine a cladding that could do the same—light and strong with efficient insulation that adapts to the environment. Biomimetic engineering could provide clothing that is light, responsive and strong and could be used in harsh site conditions. Mimicking nature could produce new designs in civil engineering that are lighter, stronger and with greater adaptability to a changing environment. New adhesives, based on those produced in nature (the blue mussel), could revolutionise the building process. Buildings could be ‘glued’ together, giving stronger,

eWork and eBusisness in architecture, engineering and construction

10

faster and cleaner construction techniques. The possibilities for the use of biomimetics appear to be endless, but the research needed to achieve effective, efficient and viable materials will not happen overnight. 2.7.2 Smart materials and structures Extensive research has been undertaken into the use of composite materials, providing lightweight, strong materials that do not rely on the earth’s non-renewable resources. These new materials, combined with the incorporation of intelligence, herald exciting scientific advances. Smart or intelligent materials or structures are those that recognise their environment and any changes and can adapt to meet those changes. System integration, mass and energy reduction are just some of the benefits of using smart materials. The technology of intelligent or ‘smart’ materials uses the knowledge of a number of different technologies such as materials science, biotechnology, biomimetics, nanotechnology, molecular electronics, neural networks and artificial intelligence. These technologies are inter-related. Just as stone implements triggered the Stone Age, alloys of copper and tin triggered the Bronze Age and iron smelting triggered the Iron Age, the new generation of materials will have a revolutionary effect. Smart materials can be further defined as (Jane and Sirkis, 1994): – Materials functioning as both sensing and actuating. – Materials that have multiple responses to one stimulus in a co-ordinated fashion. – Passively smart materials self-repairing or standby characteristics to withstand sudden changes. – Actively smart materials utilising feedback. – Smart materials and systems reproducing biological functions in load-bearing structural systems. Sensor materials should have ‘the ability to feedback stimuli such as thermal, electrical and magnetic signals, to the motor system in response to changes in the thermomechanical characteristics of smart structures’ (Jane and Sirkis, 1994). Actuators should also react to the same stimuli, but their reaction should be to change shape, stiffhess, position, natural frequency, damping and/or other mechanical characteristics. 2.7.3 Nanotechnology Nano as a prefix to any measure is a one billionth. For example, a nanosecond is one billionth of a second; a nanometre is one billionth of a metre etc. The essence of nanotechnology is the ability to create large structures from the bottom up, that is by starting with materials at a molecular level an building them up. The structures created— ‘nanostructures’ are the smallest human-made objects whose building blocks are understood from first principles in terms of their biological, chemical and physical properties. Diamonds are lightweight, very strong and have a number of materials properties that would make an ideal choice of materials for many items, from aeroplanes to cars. However, although its versatility and strength are ideal its cost/availability is not.

The future forces of change for the construction sector

11

Nanotechnology may provide the answer to this by taking manufacturing down to atomic scale. Manufactured products are made from atoms if the atoms in coal are rearranged, the result is diamonds; atoms of sand are rearranged then get computer chips are ‘born’. Rearranging the atoms in dirt, water and air produces grass (Merkle, 1997). A shatterproof diamond could be purpose ‘grown’ to provide an ideal component in the electronics, manufacturing, and construction sectors. 2.7.4 Embedded intelligence A number of industrial applications are beginning to emerge that exploit the newly emerging Internet capabilities of embedded systems. Embedded systems differ markedly from desktop systems, being fitted with just enough functionality to handle a specific application, enabling them to be produced at low-cost. Such systems have a more limited processing speed, CPU power, display capability and persistent storage capability. The challenge for developers is to produce embedded systems that are able to provide network fiinctionality within these constraints. The future is where all electronic devices are ubiquitous and networked with every object, whether it is physical or electronic, electronically tagged with information pertinent to that object. The use of physical tags will allow remote, contactless interrogation of their contents; thus, enabling all physical objects to act as nodes in a networked physical world. This technology will benefit supply chain management and inventory control, product tracking and location identification, and human-computer and human-object interfaces. In the construction sector auto-ID technologies will have a huge impact on the supply chain, the design and construction process, and facilities management (Marsh et al., 1997). 2.8 People, safety and health 2.8.1 People in a two-speed world We have a two-speed world with a widening gap between the ‘haves’ and the ‘havenots’. Large areas of the world have missed out on the information revolution, threatening to widen the gap between rich and poor—see Figure 4. We need to bridge the digital divide. According to a World Bank report ‘a global explosion of knowledge is underway which may lift hundreds of millions of the world’s poor out of poverty, or it may create a widening knowledge gap, in which poor countries lag further and further behind’. – The richest 20% of the world’s people consume 86% of all goods and services while the poorest 20% consume just 1.3%. The richest 20% consume 45% of all meat and fish, 58% of all energy used and 84% of all paper, has 74% of all telephone lines and owns 87% of all vehicles. – The three richest people in the world have assets that exceed the combined gross domestic product of the 48 least developed countries. – 2/3rds of India’s 90 million lowest-income house-holds live below the poverty line.

eWork and eBusisness in architecture, engineering and construction

12

– The estimated additional cost of achieving and maintaining universal access to basic education for all, basic health care for all, reproductive health care for all women, adequate food for all, and clean water and safe sewers for all is roughly US$40 billion a year—or less than 4% of the combined wealth of the 225 richest people in the world. The message for construction organisations is that more focus will be required on regional markets. For example, China has the knowledge and capacity to build innovative and complex structures, but it lacks the finance and the managerial efficiency. Hence, finance and managerial systems help to bridge the gap. The developing world needs appropriate technology, rather than leading edge advanced technology. Local power generation, waste water treatment, and fresh water supply will need to be designed for local provision. Affordability is key, both of the capital plant and the community’s ability to pay for the service.

Figure 4. The widening gap between the richest and the rest. Human capital is an increasingly important asset; the tacit knowledge of a business rests within its workers. Therefore, the health and work environment of construction workers needs to become more important. The overall ‘cost’ of accidents and near misses on a typical building site can amount to some 8.5% of the contract price; applied to the UK’s £84bn annual output, this is a significant cost (Minister of State for Work, Department for Work and Pensions 13 September 2003). An HSE report calculated that one third of all work fatalities happen in construction and construction workers are six times more likely to be killed at work than employees in other sectors (HSE, 2003). New construction processes will lead to greater mechanical assistance for construction workers and the elimination of dirty, dangerous and debilitating activities through the provision of advanced mechanisation. They will benefit safety (due to better ways of working) and job satisfaction (due to changes in the nature of the work accompanied by new rules for site management procedures). Short-term contracts, self-employment and job mobility will increase, creating demands for personal pensions and rental stock. Teleworking will increase, but human interaction will remain fundamentally important.

The future forces of change for the construction sector

13

New employment patterns with the old idea of the ‘employer and employee’ are becoming obsolete. No one can feel secure in the sense of lifetime employment. Only those who learn new skills will achieve long-term employability. Service providers are growing in importance with outsourcing to specialist providers. 2.8.2 Safety A focus on safety from a design and construction perspective by companies is encouraged by insurance companies and legislation, and is important to employers, employees, and public attitudes. Ultimately, safety by design will be viewed as part of the normal design process. Accident and illness prevention plans need to be built into schemes at the design stage in response to design-led safety information required by clients. Scheme safety requirements will also include information feedback reporting to originating scheme designers and to a master industry reference database. Training, advances and greater use of personal protective equipment and clothing, and using technology will combine to make the construction process safer. Better safety policies and regulations will control risks associated with construction sites and environmental decisions. Virtual reality will simulate site working environments for safety training and to help minimise vehicle movements and risks in general. Modular design, offsite prefabrication, ‘lntelligent site vehicles’ and use of robotics will reduce the number of traditional tradesmen required, leading to fewer people on-site and a reduction in accidents. Automation will also reduce the need for scaffolding and the number of people working at height. More off-site work could tackle the problems of quality, safety and speed of construction. 2.8.3 Health Over 1 billion people in the world are without safe drinking water. Almost 3 billion people (roughly half the world’s population) are without adequate sanitation in developing countries. Technology has the solutions to provide safe drinking water, but cost is the issue. 2.9 Vulnerability, security corruption and crime Different designs are being studied that minimise the impact of bomb-related threats. Structures are being designed such that a column collapse would only result in the collapse of a single floor or area without causing the collapse of the floors below it. Reinforcement of the columns in existing buildings by the use of fibre glass or carbon fibre materials is being researched and also how to minimise the impact of shattered glass. Experts are investigating the effects of the introduction of an aerosol agent into the heating, ventilation, and air-conditioning (HVAC) system through the development and installation of devices that are designed to kill microorganisms or filter harmful chemicals.

eWork and eBusisness in architecture, engineering and construction

14

2.9.1 Corruption Levels of investment, both, foreign and domestic depend on the quality of the business environment of a country. The business environment among others is a function of the rule of law, in particular the stability of rules and regulations governing business transactions, political stability and transparency. Corruption increases the uncertainty of doing business because it erodes the rule of law and is associated with high levels of bureaucratic red tape. Some describe corruption as a tax that adds to the cost of doing business. Various business surveys have concerned themselves with the prevalence of corruption in everyday business operations. An empirical analysis of transition economies in Eastern Europe and Central Asia showed that investment levels in countries with high levels of corruption were 6% lower on average than in countries with medium levels of corruption (21% and 27% respectively) (The World Bank, 2000). 2.9.2 Crime Crime is a growing industry with crime and terrorism becoming increasingly important for the built environment. The events of September 11th have highlighted the importance of life safety. Prior to that, building protection related to terrorism primarily focused on the threat of bombs detonated inside vehicles. There is now a more extensive range of threats, particularly those of a biological and chemical nature. 3 THE MESSAGE The best way to predict the fiiture is to create it—ignore the future at your peril! We have enormous potential for the future. This includes technology, improvements in communication, availability of capital, and increases in the quantity and availability of information and knowledge. These require a capacity to invent and seize opportunities, and innovative thinking. Innovation is the means by which firms can exploit change as an opportunity for a different business or service and gain a competitive advantage. The drivers above relate to a snapshot in time; they will change over time and in importance and impact. The impact on the developing world will be different to the developed world. For example, in the developing world the results of desertification, deforestation, hunger and depravation will all ultimately impact the developed world. For design and construction organisations they represent both a threat and an opportunity. REFERENCES ACRES (2002) Affordable composites from renewable sources, University of Delaware, Center for Composite Materials, USA Cabinet Office (2001) Transport: trends and challenges. Performance and innovation Unit, Cabinet Office, Her Majesty’s Government 13 November 2001 Chatham House (1998) Open Horizons Report from the Chatham House Forum. Royal Institute of International Affairs. London. ISBN 1-86203-094-4

The future forces of change for the construction sector

15

Jain, A.K. and Sirkis, J.S. (1994) Continuum damage mechanics in piezoelectric ceramics, in Adaptive structures and composite materials: analysis and application, Garcia, E., Cudney, H. and Dasgupta, A. (Eds). Presented at ASME 1994 International Mechanical Engineering Congress and Exposition, Chicago, November 6–11, pp. 47–58 Marsh, L., Flanagan R. and Finch, E. (1997) Enabling technologies: a primer on bar coding for construction. The Chartered Institute of Building, ISBN 1 85380 081 3 Merkle, RC. (1997) It’s a small, small, small, small world, MIT Technology review Feb/March issue OECD (2001) The Well-Being of Nations: The Role of Human and Social Capital. Paris: Organization for Economic Cooperation and Development OECD RAC Foundation (2002) Motoring towards 2050—an independent inquiry RAC Foundation for Motoring, London Strassmann, P.A. (1998). The value of knowledge capital. American Programmer, 11(3), pp. 3–10 The Population Institute (2004) Website: www.population-institute.org Trevipark—http://www.trevipark.co.uk UN (1999) World Urbanization Prospects, The 1999 Revision, Population Reference Bureau, UN UN (2004) World population trends on web site: http://www.undp.org/popin/wdtrends/a99/a99cht.htm UN Population Division (1996) World urbanisation prospects, New York, 1996 Urban Task Force (2000) Our Towns and Cities: the future. Urban White Paper, Office of the Deputy Prime Minister, London, UK, 183pp

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Vectors, visions and values P.S.Brandon Research Institute for the Built & Human Environment, University of Salford, Salford, UK ABSTRACT: This paper explores the circumstances which are coming together to produce revolutionary change to the way in which construction processes are being exercised. It argues that we are close to the ‘tipping point’ where a small change can have a dramatic effect. It then goes on to explore the nature of change in this context and the issues related to research and development which will aid this process. It argues that for change to occur then there must be technological development which can be measured and can give a sense of direction, then there needs to be a vision to provide the will to make things happen and lastly the change must be in line with the values which a particular society holds dear. Vectors, visions and values lie at the heart of the changes which the research community must address but perhaps the greatest of these are values.

1 INTRODUCTION One of the pre-occupations of this age is the desire to see into the future. This is understandable because the speed of change is so great that if you do not prepare then you begin to lose out in some way. This is particularly true of organisations and the concept of the ‘learning organisation’ (Senge, 1990) to prepare for change is now an established metaphor for this preparatory process. We need to learn in advance in order that when change occurs we have the tools and culture to adapt to its requirements. This has been taken a stage further with foresight studies where the scientific and technological base of whole countries has been marshalled to examine future possibilities and to prepare a research agenda to match. Over thirty countries have undertaken such exercises over the past thirty years and many have found it enormously helpful. In many cases it has been the process that seems to have been the great benefit. To get several hundred experts to engage in such a process begins to change the culture of the country towards a desire for self improvement. Within such foresight exercises there has often been sector groups looking at the needs and possibilities for major industries and of course construction being one of the major manufacturing industries of the world has received due attention. Flanagan and Jewell (2003) summarise the results of such exercises (See Table 1). Some aspects need to be interpreted because, for example, Information Technology may be assumed by some countries to be embedded in all the various aspects and therefore it does not necessarily require to be shown as a separate item. However it is, of course, a major issue. Likewise

Vectors, visions and values

17

the improvements in process, whether design, manufacture, assembly or occupation can be found within many of the assumptions made about where improvements will occur. This kind of exploration sometimes using scenario planning (Ratcliffe, 2004) is healthy for any discipline and reveals the maturity of the industry in terms of its realisation of, and the willingness to, change. It can be argued that once a corporate view takes hold, caused by sufficient people seeking and adopting the new view, that change can be rapid and revolutionary. It may be that construction is reaching such a point when it comes to the adoption of Information Technology and process improvement. 2 THE TIPPING POINT Malcolm Gladwell (2001) in his international best seller entitled ‘The Tipping Point’ identifies a phenomenon whereby an activity or a technology suddenly emulates the kind of behaviour that we see when we talk of an epidemic in medical terms. It is a significant point in time when there is a dramatic moment when everything can change at once. The situation moves from incremental to revolutionary change in what appears to the observer a very short space of time. Gladwell attempts to identify three characteristics required for this phenomenon. Firstly, contagiousness where the concept or idea suddenly becomes the

Table 1. Comparison of Foresight issues from various countries (Flanagan and Jewel). Australia Canada Finland France Germany Ireland Singapore Sweden UK USA Globalisation

Yes

Innovation/ R&D Exports/ Competitive ness

Yes

Yes

Yes

Yes

Yes

Yes

Repair & maintenance —existing stock

Yes

Yes

Yes Yes

Yes

Yes Yes

Yes

Yes

Yes

Yes

Yes

Integration— processes & people

Procurement

Yes Yes

Construction and production processes

IT

Yes

Yes

Yes Yes

Yes

Yes

Yes Yes

eWork and eBusisness in architecture, engineering and construction

18

and project delivery Service provider People/ workplace/ culture

Yes Yes

Yes

Yes

New technologies

Yes

Environment/ Yes whole life/ sustainability

Yes

Urban/city development

Yes

Governance— codes & standards

Yes

End-user demands

Yes

Yes

Yes Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes Yes Yes Yes

Yes Yes

Yes

accepted wisdom and produces a new paradigm which the vast majority follow. Secondly, a period where little causes can have big effects and thirdly, where change happens not gradually but at one dramatic moment. He applies this to many instances where social behaviour becomes revolutionary but the same can also be said of technology. It was the introduction of the personal computer which suddenly made the power of that computational machine available to the masses which in turn led to changes in communications and the way people undertook many of their normal activities whether it be leisure, or communication with friends or purchasing travel tickets or discovering knowledge. The world changed in the space of less than one working lifetime to something quite new. Partly it was contagious as the word was passed on as to what this technology could do for the everyday life of people and once imparted it was difficult to stop. Partly it was the fact that a relatively small but significant piece of software, the internet, enabled people to access knowledge and interact with it through the machine at their office or their home. Partly it was the dramatic possibilities which were seen suddenly by so many that help create a critical mass of activity which brought the investment, intellectual capital and imagination to produce the information infrastructure we have today. Of course there were many factors which aided and abetted the change but viewed from a distance these major drivers created an epidemic in human behaviour which still continues today.

Vectors, visions and values

19

3 THE TIPPING POINT FORIT IN CONSTRUCTION So what happened to the Construction Industry and the application of Information Technology? Here is an industry which appears ripe for reaping the rewards of improved communication. It requires vast stores of inter-disciplinary knowledge, it can be aided enormously by visual imaging of a finished product and the simulation of performance when at the present time the cost of physical prototyping is just too prohibitive. The recent short term forecasts for when the industry might get its act together e.g. when its supply chain will come ‘on-line’ have all proved much too optimistic. There have been significant mini epidemics, for example when contractors of all sizes suddenly found the benefit of the mobile phone to communicate in a geographically distant and often dirty and noisy environment. The industry was one of the first to take this technology on board in a big way. But what about the big changes where collaborative working in design, manufacture and operation are seen and exercised through a virtual model for the benefit of all stakeholders in the process: where remote sensing and control allows machines to manage and direct activity in what are often dirty and hazardous environments: where ordering and purchasing all resources can be done electronically: where it is possible to try before you buy and know what you are going to get and why. The industry is sometimes described as the world’s largest but here you see this great industry locked into its craft technology which in principle has not changed for millennia. The management of large projects has become more complex, certainly so has some of the structures which are now designed (Gehry, 2002) and in many cases they could not be built except for the support of computer technology. However the wide scale adoption of the machine to harness its power in a way that can be seen in, say, the aircraft industry, is just not in place despite the excellent aspirations and investment made by enlightened clients such as British Airports Authority. Where there is movement it comes from collaboration between individuals such as the way in which the Frank Gehry Partnership has worked with Dassault Systemes to adapt software originally designed for aircraft design to meet the aspirations of one of the world’s great architects. It is interesting to see that it was another industry that provided what was needed to achieve a new free form structure which has excited the world. These breakthroughs are relatively minor outbreaks of a benign driver which pave the way for what might be. The epidemic is still to come. There are signs that mass breakout is possible soon and this conference identifies the work of some of the ‘thought leaders’ in the field. It addresses what is happening, what might happen, what should happen and what should definitely not happen! Although the term ‘thought leader’ seems to have Orwellian overtones it does capture one important aspect. It identifies the power of thought and the imagination to provide visions of the possible. This aids the first ingredient of the ‘tipping point’, that of contagion. So what of the other two ingredients? If we can identify little causes which can have big effects then we may be well on the way to radical change. A view of the industrial/social world we live in would provide us with the following trends which coming together might provide the spark for ingredient number two. As with all epidemics it is impossible to predict but somewhere in the soup

eWork and eBusisness in architecture, engineering and construction

20

of ideas and developments lurks a minor change which will revolutionise the way the construction industry works. • Convergence: The last decade has seen a massive change in digital technologies which has seen all forms of media whether it be visual imagery, radio, television, audio, personal computers or telephone communications all come together in one digital representation. Mobile phones today now have the capacity to bring most of these aspects together. It does not end there. Society across the world is changing and despite resistance in some quarters there is much more sharing of knowledge leading to a common or converging viewpoint which may in the long run lead to globalisation of values. The seduction by western values is seen by many to be one of the downsides of such open access which is controlled by a few. Will the construction industry come together in a way we have never seen before? • Connectivity: Alongside the convergence through technologies has been the vast increase in communication and the access we have in the developed world to all forms of information. We can now be ‘connected’ anytime any place anywhere and with the development of ambient computing this is going to extend still further. With connectivity comes contact, access and the inability to hold on to and protect specialist information for more than a short period. The hold of the professions and their ‘fortresses of knowledge’ protected by their examination systems and barriers to entry begins to disappear and boundaries between knowledge disappear. Connectivity allows us to change quickly and for the ‘virus’ of change to move through the population unfettered, unleashing a contagion of ideas which can tip us into a new and unknown situation. • Culture: As the technologies converge and connectivity allows the spread of the contagious idea then it needs a receptive culture within which it is easy to ‘breed’. The present generation of university leavers are the first cohort of graduates who have been through the complete school system where information technology was an integral part of the curriculum from the very first year of entry into education. To them it is the norm whereas to previous generations it had to be learnt and absorbed and systems had to be re-learnt to embrace change. The information technological change is now endemic in society as a whole and it is even stranger to be outside it than to be in it. • Creativity: Do computers release creativity or constrain it? In past generations the need to standardise and formalise to use the machine was prevalent. Now this is changing as the nature of the machine becomes more flexible and adaptive. There is still a long way to go and the culture has changed so that there is mutual give and take between machine and user to which both are becoming more accustomed. The games industry is a leading example where the users speak the language and seldom seem to have to read any rule book before they can participate at a high level. This natural take up needs to extend to industries like construction. • Content improvement: As the content of what is provided through the technology improves so it is more likely that more people will want to use it. When that content of knowledge or access becomes indispensable for normal living then the technology also becomes indispensable. In the developed nations we are getting close to this situation as our financial, employment, consumerism etc is being built around electronic processing. For the construction industry we have some way to go but the industry is a

Vectors, visions and values

21

laggard in the race towards electronic business and falls sharply behind transport, banking and other sectors. • Collaborative working: When the stakeholders need to work together for maximum efficiency and they are geographically separated then the drive for integrated communication and sharing becomes paramount. In addition the real benefits often arise when the stakeholders work together and it is just not possible for one organisation to act alone. The benefits of airline booking of tickets would not be as successful if each company developed its own system which could not speak to the others. Where the benefit is of this nature it may be necessary for Government or a major player in the software industry to take the lead. In addition there must be willingness for all parties to work together in pre-competitive research to establish the platform. • Content: With the growing developments in the hard technologies comes an increased impetus to provide the content for users to find the technology even more usefiil. The entertainment industry has been one of the first to realise the potential for extra services and education is following close behind, often using the same technology. It has been argued that the distribution networks required for the content may create a monopoly of knowledge, not unlike the half a dozen or so global film distributors who control the films made available to us for general viewing. This could be dangerous as we then leave the access to knowledge and the values that the knowledge conveys in the hands of a few. • Cost reduction: As quickly as a new refinement to the technology takes hold then an improved version is produced. This highly competitive market creates a leap frogging effect which sometimes leaves the purchaser bewildered and unable to invest without substantial risk. However the overall impact is for more computing power to become available to each individual which in turn enables him or her to do more for the same cost and in some cases to be more flexible in their use of the technology, thus removing some of the barriers to use. • Common Standards: This may be a temporary factor in the tipping point agenda. The technology is moving so fast that the hurdles we see now to inter-operability are likely to disappear and the issue will become unimportant. However for the time being the move towards standards for inter-operability such as the Industry Foundation Classes (IFCs) is opening the opportunity to exchange information and to integrate processes together. This in turn allows the collaborative working around a single model which has long been the holy grail of the IT model builders. We may well find within the above list that key activity which will tip the balance and bring the construction industry to the fore in e-business. It is likely to be a combination of many of the above but one new development could well take us into a new digital craftsmanship to replace the old. If this is about to happen and many think the time is ripe then we need to consider future possibilities and what it might be like to live in this new world. What will be the advantages and the pitfalls? To do this we need to consider the manner in which we approach the subject. This can be considered under three headings namely, vectors, visions and values. All three share a degree of inter-dependence but all three have significant lessons to teach us.

eWork and eBusisness in architecture, engineering and construction

22

4 VECTORS A vector is defined in one dictionary as ‘a quantity completely specifled by magnitude and direction’. It is the realm of quantitative research and the fruitful field of the PhD student. By measuring and refining and postulating and experimenting we see how we might change the status quo and determine what factors contribute to our understanding of an item or aspect. Even in qualitative research we often seek the quantification of our findings through surveys and other mechanisms although in most cases we would hesitate to say we have ‘completely specifled the magnitude’. It is also the field of systems which specify how things behave, often in an integrated way. It has been the mechanisms by which scientific method has enabled us to advance. By nature it tends to be reductionist, reducing the problem to something which we can handle and understand although often we lose the impact on other aspects of the world we live in. It is often the field of the short term, dealing with the problems as we see it today. If we take the information technology developments we can see how harnessing the technology coupled with an understanding of science to aid in imagination, manufacture and use has produced significant developments. If we link this with the idea of ‘direction’ then we move into what will form the next research agenda. The European Fifth Framework project called ‘ROADCON’ (‘Strategic RTD Roadmap for ICT in Construction’, 2001) attempted to identify where we are now in terms of IT and the roadmap of where we should be going—the direction. This is a summary of what was listed: • Applications – Current: These are dedicated to specific engineering functions andproject/building life cycle stages. – Future: Total life cycle appraisal supported by user-friendly functional applications and persistent data ensuring holistic decision making. • Products and Components – Current: Have little ‘added value’ to the building operation. – Future: A mixture of high and low value components acting intelligently. • Knowledge re-use – Current: Relies on industry wide sharing of experiences and fiindamental understanding of complex systems interacting at all levels. – Future: Experience and previous solutions are available in personal and departmental archives but new solutions are regularly re-invented in every project. • Information access – Current Company and project data available via LANs and web based technologies. – Future: Ambient access provided, anytime, anywhere, by industry wide communications infrastructure, distributed and embedded systems, ambient intelligence and mobile computing. • Project Information and Communication technologies

Vectors, visions and values

23

– Current: Based on ICTs which augment the creation and sharing of humaninterpretable information. – Future: Based on model based ICT enabling context awareness, automation, simulation and visualisation based on computer interpretable data. • Nature of technology – Current: Invasive technology where the user has to adapt to proven and emerging technologies. – Future: Technology is human-centred based around design and build paradigms promoted by ICTs that enhance the social condition of individuals in the society. • Data Exchange – Current: Available at file level between different applications and companies based mainly on proprietary formats at low semantic level. – Future: Flexible inter-operability between heterogeneous ICT systems which allows seamless interaction between all stakeholders. • Processes – Current: Business processes are driven by lowest cost but there is a growing awareness of customer perceived value which is not supported by prevailing business models. – Future: Performance driven process assuring compliance with clients’ requirements and emphasis on customer perceived value. • Collaborative teams – Current: Teamwork between distributed experts in participating companies is supported by web-enabled document management systems in ‘project web sites’. – Future: Virtual teams combine distributed competences via global collaboration environments that support cultural, linguistic, social and legal transparency. • Systems Flexibility – Current ICTs require customisation to meet the varying needs of users and has to be tailor-made for new situations requiring manual maintenance, configuration and support. – Future: Adaptive systems are created which learn from their own use and user behaviour, and are able to adapt to new situations without manual maintenance, configuration and support. The above list suggests where development might take place to overcome some of the difficulties we face today and provide a working environment which is more finely attuned to the needs of human beings. It is technology centred and is looking for technical solutions. To obtain these solutions then quantitative measures are needed for the science to produce the tools and the technology to make use of scientific discovery. Much will be based on an understanding of the natural sciences and the engineering necessary to make the science useful. In this broad sense the work is in the realm of the vector, ‘quantities

eWork and eBusisness in architecture, engineering and construction

24

completely specified in magnitude and direction’. Without measurement and direction through an understanding of what is possible these advances could not take place. But is this all? What else needs to be considered? Here we come to the realm of the vision. 5 VISION It is possible to have an over abundance of technical solutions but without change occurring. In the early days of information technology the term ‘solutions in search of a problem’ was often used. By this was meant that the technology was advancing so fast that it was outstripping the ability of society to assimilate it in a meaningfiil way. Often its use was lost on the community it was meant to benefit, or worse, the creator had designed something which genuinely had no use for the foreseeable future. In the former case it is critical that society has some vision of what it wants to achieve in order for it to take advantage of the new tools. To do this it needs a vision. One dictionary definition of vision is ‘lntelligent Foresight’. In this sense, then, the intelligence gathered from the vectors can be used to give an insight into the future. The difference between ‘foresight’ and ‘forecasting’ is that forecasting attempts to predict the future (whether it is events, technological advances or expected dates for occurrence) whereas foresight tries

Table 2. Visions and themes for the Australian Construction Industry 2020 (Hampson & Brandon). Potential impacts Design & Communication

Process & manufacture

5. Information & communication technologies

6. Virtual prototyping process

7. Off-site manufacture

8. Improved manufacturing

1. Environmentally sustainable construction

Strong

Medium

Strong

Strong

2. Meeting client needs

Strong

Strong

Weak

Strong

3. Improved business environment

Strong

Medium

Weak

Medium

4. Improvement of labour force

Strong

Medium

Strong

Strong

9. Research and innovation

Strong

Strong

Strong

Strong

to provide guidelines for policy makers about the directions they should follow. In one case (forecasting) the industry asks ‘how do I respond to these events?’ knowing they are

Vectors, visions and values

25

powerless to do anything about them and in the other (foresight) the industry asks ‘what do I need to achieve these goals?’ It is the difference between saying the future is inevitable and we just have to predict what will happen and on the other hand saying we can influence the future, we are not just helpless bystanders. The most recent foresight study is the Construction 2020 Vision arranged through the CRC Construction based at Queensland University of Technology, Brisbane, Australia, involving all the major organisations and professions in the industry. Several hundred people attended workshops and completed questionnaires in which they identified their vision for an improved Australian Construction industry. The final summary report of these deliberations (Hampson & Brandon, 2004) reveals the integrated nature of the aspirations of the industry. Table 2 shows the broad outline of the nine visions or themes distilled from all the responses made. On one axis it can be seen that it is the ‘environment’ in which construction takes place which is the key issues. (Environment here means the complex of social and cultural conditions affecting the nature of an individual or community). These include the needs of the workforce, a sustainable environment, responding to clients’ needs, an improved business environment and research and development. On the other axis are the technologies which might well aid the improvement in the environments identified and these include process issues and those related to ICTs. The strength of relationship does of course vary between the two. What is interesting here is that it is not the technologies which dominate. In fact in the analysis of responses it was the improved business environment and environmentally sustainable construction which headed the list. The technologies, although considered important, were seen as a means by which the other issues could be achieved. In other words, it was the people issues which were really considered to be important, whether it was now (as in the case of the business environment) or in the future (as in the case of sustainable development). This suggests that visions of the future as expressed in peoples’ aspirations are more about quality of life rather than mere technological advance. This may well be something we should note as we invest our time and energy into issues of self improvement. In fact the drive is towards values rather than solutions to current technological problems. This is also more evident as people are asked to look into the longer term future rather than the short and medium term. What we see is a shift to values the more we leave the baggage of the present behind. 6 VALUES At the heart of values are the belief systems to which we hold. These in turn are arise from or are created by the culture in which we live. In democratic societies, at least, these are partially enshrined in the legislation and regulation which the people have determined to represent those values. Whilst in past times these matters were largely stable and often confined by national or other boundaries, this is not so true today. The internet and other technologies do not recognise such boundaries and can pose a threat to those who hold strong beliefs. We are moving into a period when values are becoming a key issue in development and world politics as globalisation begins to be the mantra of the many.

eWork and eBusisness in architecture, engineering and construction

26

When we consider the research agenda for countries the question of values is often forgotten in our desire to improve the systems and technologies with which we work. When the Australian community calls for a better business environment, what is it calling for? Does it mean ‘more profits for all’ and if so does this mean that someone else will suffer? Does it mean a fairer distribution of risk, in which case who wins and who loses, assuming the present system is unsatisfactory. Does it mean that those with technology win and those without lose? It is a very complex issue but one that is fiindamental to the well-being of the people we seek to serve. Our research cannot be undertaken, and a new tool produced, without considering whether people want it, whether it has negative as well as positive contributions to make or whether it supports or undermines the values of the society in which it is to be used. These matters are critical in the information sciences. Knowledge is not neutral, it empowers some and can disempower others. At the same time the technologies used to convey knowledge use models, which by definition, are not fiilly representative of the object or system they try to represent. They represent the item but they do not convey it in its entirety. We are moving to the creation of a virtual world where we aim to create reality within a machine. As we move in this direction we begin to touch on some very key and sensitive issues. How do we really know that this new world truly reflects our own? Even if it does—are we interpreting it in the right way? In the real world it only affects a small number of individuals and changes can be made and the model adapted. Computer models on the other hand are designed to be used time and time again by many people who do not necessarily communicate with each other. Mistakes become fossilized and values become frozen to the point where an oppressive tool may have been created. The author, as a programmer, many years ago was concerned by some of the knowledge he was placing in some computer programmes. In several programming languages the expression ‘IF…THEN’ was common. IF a certain set of circumstances existed THEN a certain action was taken. At the time we were writing into the programme well recognised techniques and best practice but what if our knowledge increased or society did not want to implement that action when that set of circumstances occurred? In a simple program it could be changed but not before many had used it or still continued to use it. In a complex program the piece of knowledge became embedded so deep that it was often impossible to find it and extract it and change it. It became part of the system and it was almost impossible to detect the manner in which it influenced the full model or program. This became even more acute when Knowledge Based Systems came into being. We captured the knowledge of ‘experts’ and we made that available to those who were less expert. The knowledge of the expert and to some extent his or her value system was now built into the model. We tried to devise ways round this by designating some knowledge as stable (but who says so) and some as unstable and therefore made more explicit and easy to change. This can work in relatively small systems dealing with focussed applications but the trend is towards integrated systems and greater ‘intelligence’ for the machine. In other words we will be leaving more of the decision making to the machine. What algorithms will the machine use and how many of these will represent values? When we begin to have ‘conversation’ with the machine how do we know what mechanisms it is using to guide us towards a particular solution?

Vectors, visions and values

27

This is but one example of where technology is taking us into the value systems arena, although some would argue that we have been there for some time. These are not trivial matters. As we allow machines to intrude on our privacy and on our decision-making are we going to be constantly challenging its reasoning powers as we do in debate and conversation? How will we get all of us to ‘buy in’ to what it is doing when the users are not a coherent homogenous group who can exercise some kind of democratic power? We are already talking about ‘jacking in’ computers direct into the brain. This raises even greater questions about at which point the brain leaves being human and becomes a machine and who provides its value system, man or machine? This must seem like science fiction to some but it is coming upon us fast. In our research we must ask the question about what we are creating and how this really ties in with the aspirations of our fellow human kind to have a reasonable quality of life. There should come a point when every piece of research but particularly research in terms of knowledge and processes should require a set of questions to be asked about how it impacts upon the society which it seeks to serve. 7 CONCLUDING REMARKS This paper has attempted to raise some fundamental questions about the research we do, particularly in the field of information and communication technologies, but also in the way we do it. It has recognised the great debt we owe to scientific method and the reductionist approach which has provided advances from which we have all benefited. This is the realm of the vector where measurement reigns supreme. It has also recognised the importance of looking to the future to provide further direction to our efforts. Here studies are finding increasingly that it is quality of life issues which now dominate, rather than technology. Technology is seen as enabler but needs to be kept in its place. The need to know the general direction we are heading in is a key to investment and efficient utilisation of resources. The faster the speed of change then the greater the need to envision where we are going. With an increase in speed, so must the headlights become stronger! As we move toward quality of life then we begin to embrace the values of people and their aspirations. The vision for the future must address these issues. Finally these values need to be subject to constant debate and exploration and the technology must be sufficiently transparent and flexible to adopt the conclusions of the debate or else we will create a monster of horrific proportions. Whether these approaches result in the tipping point is unknown. It is likely that it is the combination of scientific method scenario planning and a response to values which will provide the changes that will see Construction move in a way which has been seen by many industries. These issues around construction are now reaching a crescendo of movement which seems to suggest that this point is near and we need to consider what part each of us should play. In conclusion vectors underpin our understanding of the future and provide material for our visions; visions allow us to provide scenarios in which we can mould events and seek to match the aspirations of society; values underpin all that we do and unless these are part of the foregoing processes then we may be undermining the very progress we are trying to achieve. Values should dominate if the tipping point is to provide us with a

eWork and eBusisness in architecture, engineering and construction

28

technological base which will be human centred and serve humankind and our industry well. REFERENCES Flanagan, R. & Jewell, C. 2003. A Review of Recent Work on Construction Futures. London.: CRISP Commission 02/06, Construction Research and Strategy Panel Gehry, J. 2002. Gehry Talks. Architecture+Process. USA: Universe Press Gladwell, M. 2001. The Tipping Point. UK: Abacus Hampson, K. & Brandon, P. 2004. Construction 2020-A Vision for Australia’s Property and Construction Industry. Australia: CRC for Construction Innovation, QUT, Brisbane Ratcliffe, J. 2004. Imagineering the Future—the prospective process through scenario thinking for strategic planning and management; a tool for exploring IT futures in Designing Managing and Supporting Construction Projects Through Innovation and IT solutions (Editors Brandon, P. Heng Li, Shaffii, N. & Shen, Q.) Malaysia: CIDB ROADCON: Strategic RTD Roadmap for ICT in Construction. 2001. European Fifth Framework Project. (IST-2001-37278) Senge, P. 1990. The Fifth Discipline—the Art andPractice of the Learning Organisation. London: Random House

eWork and eBusiness in Architecture, Engineering and Construction—Dlkbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Help wanted: project information officer T.M.Froese University of British Columbia, Vancouver, BC.Canada ABSTRACT: Innovations in information technologies promise significant improvements in the effectiveness and efficiency of designing and managing construction projects. Yet the new demands that these information technologies create for expertise and management tasks may be more than typical project personnel can accommodate. This paper explores the potential for introducing a new role into the project team— that of a project information officer. The paper is organized in the form of a hypothetical job description for such a position. It first described the duties of the project information officer relating to the implementation of an information management plan, the specific project systems to be used, and new approaches to overall project management. The paper then discusses the organizational role, skills and qualifications, and the compensation and evaluation issues for the position.

1 INTRODUCTION Current trends in information technology (IT) are yielding a wide range of new computer-based tools to support the architecture, engineering, construction and facilities management (AEC/FM) industries—everything from project collaboration Web sites to virtual building environments. These tools promise great increases in the effectiveness and efficiency of designing and managing construction projects. However, no one claims that these improvements will come without cost in terms of new skills and work tasks that will be required of many of the project participants. These new requirements are often required of senior project designers and managers. Yet the reality of the AEC/FM industry is that these people will rarely be in the position to take on these new requirements. They can typically be characterized as busy, highly effective people, and in the spirit of “putting first things first” (Covey 1990), taking the time to learn and implement new IT will rarely be at the top of their priority list, regardless of the expected benefits. Moreover, trends towards the integration of information resources create new requirements for project-wide information coordination, which must be administered by someone. To address these practical barriers to IT innovation, we suggest that a new role is required for AEC/FM projects—that of a Project Information Officer. This paper explores the anticipated roles and requirements of the Project Information Officer in the form of a hypothetical job description for such a person.

eWork and eBusisness in architecture, engineering and construction

30

2 HELP WANTED: PROJECT INFORMATION OFFICER A position is available for a Project Information Offlcer (PIO) for a large AEC/FM project. The PIO will be responsible for the overall information management on the project, information technology strategy and implementation, information integration and coordination for the project, and related training activities for project participants. 3 DUTIES OF THE PROJECT INFORMATION OFFICER The duties required of the PIO are organized into three main categories: implementing an information management plan, project systems and areas of expertise, and assisting in the implementation of a unified approach to project management. Each of these is discussed in the following sections. 3.1 Implementing an information management plan for the project The PIO will be responsible for implementing an overall information management plan for the project. The information management plan will address three primary elements: project tasks, information transactions, and overall integration issues. For each of these elements, the plan will analyze information requirements, design information management solutions, and produce specific information management deliverables. Each of these tasks is described more fully below. The level of detail required for the breakdown of project tasks and transactions described below will be as needed to achieve an effective overall project information management system. In general, this will be at a level where distinct work packages interact with each other, not the level at which work is carried out within the work packages themselves (for example, it will address the type and form of design information that must be sent to the general contractor, but not the way that individual designers must carry out their design tasks). 3.1.1 Elements of an information management framework The information management plan is based upon an overall information management framework that adopts an underlying process model for AEC/FM projects. This model views projects in terms of the following elements (illustrated in Figure 1): • A collection of tasks carried out by project participants (all tasks required to design and construct the facility, including tasks relating to archiving project information, providing information to facility users/operators, etc.). • A collection of transactions that communicate information between tasks. • A collection of integration issues—issues relating to the interactions between the tasks and transactions as a whole rather than as a set of individual elements. This also includes issues relating to information integration across organizational boundaries,

Help wanted: project information officer

31

integration of legacy and existing technology with plans for new and ftiture technology, and so on. The model considers these elements across all project participants. The information management tasks described below are carried out for each of these project elements. 3.1.2 Analysis of information management elements As the first step in developing the information management plan, the PIO will analyze each element (tasks, transactions, and integration issues) to assess the overall information requirements, as follows: • Define each task, transaction, or integration issue, including identifying participants, project phase, etc. This should correspond largely to an overall project plan, and thus it may not need to be done as a distinct activity. • Assess the signiflcant information requirements for each element: Determine, in general terms, the type of information required for carrying out the tasks, the information communicated in the transactions, or the requirements for integration issues. With traditional information technologies, information requirements generally correspond to specific paper or electronic documents. With newer information technologies, however, information requirements can involve access to specific data sources (such as shared databases) that do not correspond to traditional documents. • Assess tool requirements: Determine key software applications used in carrying out tasks, communication technologies used for transactions, or standards used to support integration.

Figure 1. Elements of an information management framework that considers projects in terms of tasks, transactions, and overall integration issues. From an information perspective, tasks are

eWork and eBusisness in architecture, engineering and construction

32

associated with computer applications and transactions are associated with documents. • Assess the information outputs: Determine the significant information produced by each task. This typically corresponds to information required as inputs to other tasks. 3.1.3 Design of information management elements Given the analysis of the project information requirements (as established in the previous section) the PIO will design the information management strategies and solutions for the project and formalize the requirements that the overall plan will place on each of the project elements, as follows: • Formalize information input and output requirements: the requirements analyzed previously will be formalize as the information required as inputs for each task, and the information that each task must commit to producing. • Requirements for tools, technologies, standards, etc.: establish the basic requirements, constraints, and recommendations for the software tools used to support individual tasks, communication technologies used for transactions, and data standards adopted to support integration, etc. • Staffing requirements: define roles and responsibilities relating to information management. • Work practices and procedures: establish requirements and constraints on how various work tasks are carried out in order to assure information management requirements can be met. In deciding from among alternative solutions for the above strategies, an overall costbenefit analysis approach will be followed. This may not be a straightforward process, however, since the costs involved in improving information management elements may be incurred by parties that are different from those that receive the resulting benefits. 3.1.4 Deliverables of the project information officer The PIO will be responsible for the following specific outputs: • Information management plan documents: The requirements for information management strategies and solutions as described in the previous section will be formalized into a documented information management plan for the project. This will include the minimum requirements that individual tasks and participants must meet, and additional optional recommendations. • Implementation of the information management plan: The PIO will be responsible for all aspects of implementing the information management plan. This includes coordination among all key project participants (for example, holding regular information management coordination meetings), carrying out administrative duties for the plan, monitoring conformance and results, and so on.

Help wanted: project information officer

33

• Training: The PIO will organize the training necessary for project participants to carry out the information management plan. This will be especially necessary in the case of new information technology. • Provide project information technology resources: The PIO will be responsible for acquiring and supporting any information technology resources (computing hardware and software) that are best provided for the project as a whole, as opposed to individual participants (for example, this may include a project collaboration web site, but not specific CAD software). •Provide information management and technology support for project participants: The PIO will act as a resource available to all key project participants on issues relating to information management and technology. 3.2 Project systems and areas of expertise It is anticipated that the specific types of information systems used during project will be as described in the following list. The PIO is required to have a basic expertise in all of these areas, and to include each of these with in the information management plan. • Project document management and collaboration web site: a web site will be established for the project that will act as the central document management and collaboration vehicle for the project. This will include user accounts for all project participants, access control for project information, online forms and workflows, messaging, contact list, etc. A commercial service will be used to create and host the site. • Classification systems, project break downs structures and codes, and folder structures: much of the project information will be organized according to various forms of classification systems. These range from the use of industry-standard numbering schemes for specification documents, to the use of a project work breakdowns structure, to the creation of a hierarchical folder structure for documents placed on the project web site. The PIO must have familiarity with relevant industry classification systems such as OCCS (OCCS Development Committee 2004), and will be responsible for establishing the project classification systems. • Model-based interoperability: many of the systems described below work with modelbased project data, and have the potential to exchange this data with other types of systems. The project will adopt a model-based interoperability approach for data exchange for the lifecycle of the project. The PIO must be familiar with the relevant data exchange standards, in particular the IFCs (International Alliance for Interoperability 2004), and must establish specific requirements and policies for project data interoperability. The PIO must also establish a central repository for the project modelbased data (a model server). • Requirements management system: a requirements management tool will be used to capture significant project requirements through all phases of the project and to assure that these requirements are satisfied during the design in execution of the work. • Model-based architectural design: The architectural design for the building will be carried out using model based design tools (e.g., object-based CAD). Although this improves the effectiveness of the architectural design process, the primary

eWork and eBusisness in architecture, engineering and construction

34

motivation here is the use of the resulting building information model as input to many of the downstream activities and systems. • Visualization: using the building information model, which includes full 3-D geometry, there will be extensive use of visualization to capture requirements and identify issues with the users, designers, and builders. This may include high-end virtual reality environments (e.g., immersive 3-D visualization), on-site visualization facilities, etc. • Model-based engineering analysis and design: the building information model will be used as preliminary input for a number of specialized engineering analysis and design tools for structural, building systems, sustainability, etc. • Project costs and value engineering: the building information model will be used as input to cost estimating and value engineering systems. These will be used at numerous points through the lifecycle of the project (with varying degrees of accuracy). • Construction planning and control’. the project will make use of systems for effective schedule planning and control, short interval planning and production engineering, operation simulation, esource planning, etc. Again, the systems will make use of the building information model and will link into other project information for purposes such as 4-D simulation. • E-procurement: project participants will make use of on-line electronic systems to support all aspects of procurement, including E-bidding/tendering, project plans are rooms, etc. • E-transactions: on-line systems will be available for most common project transactions, such as requests for information, progress payments claims, etc. These will be available through the project web site. • E-legal strategy: project policies and agreements will be in place to address legal issues relating to the electronic project transactions. • Handoff of project information to facilities management and project archives: systems and procedures will be in place to ensure that complete and efficient package of project information is handed off from design and construction to ongoing facilities operation and management, as well as maintained as archives of the project 3.3 Assist in the implementation of a unifled approach to project management It has been argued that there is a fundamental mismatch between emerging IT solutions for AEC/FM and current project management practices (Froese and Staub-French 2003). The IT solutions rely on a high degree of integration and collaboration, whereas current practice makes heavy use of decomposition and modularization to minimize interdependencies between project tasks and participants. IT developers must strive to accommodate current practice, yet project management practice may also need to adapt in order to take full advantage of the capabilities offered by emerging IT solutions. The proposed project will adopt these modifications and use a unified approach to project management. In this unified approach, the work is still carried out by defining distinct work packages and assigning these to individual project participant groups.

Help wanted: project information officer

35

However, there is much more emphasis on a continuously evolving project deliverable, where this deliverable is initially the building information model, which expands with new information over time until, during the construction phase, the building information model is used to drive the production of the physical building itself. The focus of the individual work tasks, then, is to draw necessary information from the building information model and add new content back into the building information model or new components into the physical building. Information technology plays a critical component of this new unified approach to project management, since it relies on the ability for project participants to collaborate on the building information model. More specifically, the approach uses the following standard views as the primary conceptual structures that are shared and are common to all prqject participants (these are illustrated in Figure 2): • The project lifecycle view: a time-based view that organizes project information into well-defined project phases. • The workflow view: a process-based view that organizes project information into work packages and tasks. • The product/deliverable view: views project information in terms of the specific information or physical components of the overall project.

Figure 2. Schematic illustration of three primary views of project information and their interrelationships in a unified approach to project management. The PIO will work with project managers to help design and implement a unified approach to project management that can fully leverage the opportunities offered by the project IT.

4 ORGANIZATIONAL ROLE

eWork and eBusisness in architecture, engineering and construction

36

The PIO may be an employee of the project owner, lead designer, or lead contractor organizations, or may work as an independent consultant/contractor. Regardless of employer, the PIO will be considered to be a resource to the project as a whole, not to an individual project participant organization. The PIO will be a senior management-level position within the project organization (i.e., not a junior technology support position). The PIO will report to the owner’s project representative and will work with an information management committee consisting of project managers and information specialists from key project participants. Depending upon the size of the project, the PIO will have an independent staff. In addition to the information management committee, liaison positions will be assigned within each project participant organization. 5 SKILLS AND QUALIFICATIONS Candidates for the position of PIO will be required to have a thorough understanding of the AEC/FM industry, information management and organizational issues, data interoperability issues, and best practices for software tools and procedures for all of the major project systems described previously. Candidates with be expected to possess a master’s degree relating to construction IT and experience with information management on at least one similar project. 6 COMPENSATION AND EVALUATION Advanced construction IT offers great promise for improving the project effectiveness and efficiency while reducing risk. Not all of these benefits directly reduce costs, yet the overall assumption is that the costs of the PIO position will be fiilly realized through project cost savings. This will not be a direct measure, but will be assessed on an overall qualitative basis through an information management review processes that examines the following questions of the information management and technology for the project: • To what degree was waste (any non-value-adding activity) reduced? • What new functionality was available? • How efficient and problem-free was the informa tion management and technology relative to projects with similar levels of IT in the past? • What was the level of service and management effectiveness offered by the PIO? • What is the potential for future improvements gained by the information management practices on this project (i.e., recognizing the long learning curve that may be associated with new IT)?

Help wanted: project information officer

37

7 CONCLUSIONS The description of a PIO role and an overall project information management context described in this paper is preliminary, incomplete, and overly idealistic. Many of the tasks and technologies described here are currently in place on construction projects. However, the position of a project information officer and information management procedures of the nature described here could go a long way towards easing some of the significant practical barriers that stand between emerging IT solutions and real improvements to construction projects. Next steps would include collecting best practices for information management on construction projects, further development and refinement of an information management process, and greater inclusion of overall information management practices as part of IT research and development projects. REFERENCES Covey, S. (1990) The 7 habits of Highly Effective People, Fireside: New York. Froese, T. and Staub-French, S. (2003). “A Unified Approach to Project Management,” 4th Joint Symposium on Information Technology in Civil Engineering, ASCE, Nashville, USA, Nov. 2003. International Alliance for Interoperability (2004), IAI International Home Page, URL: http://www.iai-international.org/iai_international/ (accessed June 3, 2004). OCCS Development Committee, (2004). “OCCS Net, The Omniclass Construction Classification System”, web page at: http://www.occsnet.org/ [accessed June 24, 2004].

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

The next generation of eBusiness and eWork—what is needed for the systemic innovation? An executive summary of the EU supporting research and innovation B.Salmelin Head of Unit DG Information Society, New Working Environments ABSTRACT: The presentation is building on three main pillars: Firstly the policy context of the EU is described, in the context of industrial competition and the new innovation processes. Secondly the presentation is looking in detail to the drivers the knowledge, networked economy is bringing to the sustainable economical growth and thirdly describing the IST research programme, and also the new thinking of the EU regarding new research policy instruments favouring the full deployment of the European research capacity. The EU has set it policy goals towards 2010 in the well-known Lisbon Agenda. It is an important document form several perspectives: It sets the ambition of Europe towards sustainable growth, competitiveness and high-quality jobs. The timeline was set to incorporate the enlargement process which is halfway done now, increasing the social cohesion policy implications. However the real issue is how to receive the Lisbon goals. In the speech it is shown that the need for breaking from the past paradigms is evident, and this view is backed up by some recent studies on the productivity growth due to new paradigms. The growth reported by using modern ICT technologies in an innovative, systemic way is reported to be several tens of percent, in average. This brings challenges to organisational behaviour and their fiiture developments. Virtual organisations have been talked about for tens of years, but are there really those, in the meaning of organisations being at the same time capturing the advantage of being small, thus flexible and at the same time large, thus effective? Not so many. Perhaps the construction sector itself is leading the way towards the new organisation formats. We can not either forget the role of entirely new forms of organising the work, like in and by professional communities rather than fixed organisations. The networking and connectivity together with advanced collaboration tools lead to entirely new possibilities to build virtual (e.g. design) tams across traditional boundaries, and even continents. The 24 hours continuous work paradigm is very close, and promising. What is required though on policy and legislation levels? Do we need to reconsider the IPR issues when approaching these new paradigms not to inhibit innovation?

The next generation of eBusiness and eWork

39

Some key projects running in the field of new working paradigms are described to illustrate the possibilities the technology is providing already today, not to talk about tomorrow. The third part of the speech continues precise information of the experiences the EU has from past projects in the field, the achievements and also the experiences of the first and second call of the IST programme where themes like networked business and mobile work were present. The third call which is closing these days is elaborated in the perspective of the longterm goals of the EU in constructing new undertakings and instruments to capture better the whole innovation process, which has moved from sequential to strongly parallel, more dynamic and multidisciplinary than ever before. Here a new approach to the building of the research and innovation agenda is described. The unit New Working Environments of DG Information Society has started a set of research communities, interacting in a multidisciplinary way. The communities consist of industrial and research actors, policy makers and those who are needed to cover the whole innovation process. This set of communities, called ami@work (Ambient Intelligence at work) are now in the start-up phase, but already encompassing more than 600 people being actively involved. The site can be found under www.amiatwork.com, which is inviting you all to participate in those communities closest to you. As example of supporting the innovation process on national base is also described, to illustrate the needed interactions for full efficiency. Industrial and research community participation is encouraged to make the interactions and thus the whole innovation process more effective. The fourth IST call, which is to be published at the yearly IST 2004 conference, this year in the Hague, The Netherlands is discussed as the whole IST research work programme 2005–2006, which is investing in IST research some 1,8 Billion EURO in the forthcoming two years. New themes are approaching, and the background thinking leading to this is described. Last but not least the path towards the 7th EU research Framework programme is described. The proposal from the Commission is to double the research investment to match with the goals of 3% of research of the GDP following the Lisbon agenda goals. New instruments like technology platforms are debated, as well as the balance between the long-term (individual) research versus the current collaborative research schemes. The state of the play and the rationale of the choices will be discussed. Also the next steps opening participation possibilities for the industry and research sectors are described to encourage the common way to meet the sustainable growth goals.

Product modelling technology

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Virtual building maintenance: enhancing building maintenance using 3D-GIS and 3D laser scanner (VR) technology V.Ahmed, Y.Arayici, A.Hamilton & G.Aouad School of Construction and Property Management, University of Salford, Greater Manchester, United Kingdom ABSTRACT: The renovation and refurbishment market is rapidly expanding within the construction industry, bringing the role of the Facilities Management (FM) department to the forefront. Operating and maintaining a facility however, takes the biggest proportion of the lifecycle cost of a building, which can be costly and time consuming. The wide spread and use of advanced technologies within the construction industry can be used to drive the productivity gains by promoting a freeflow of information between departments, divisions, offices, and sites; and between themselves, their contractors and partners. The paper describes a scope in the INTELCITIES project undertaken by 75 partners including 18 cities (Manchester, Rome, Barcelona, etc), 20ICT companies (Nokia, IBM, CISCO, Microsoft, etc) and 38 research institutes (University of Salford from UK, CSTB from France, UPC from Spain, etc) across Europe to pool advanced knowledge and experience of electronic government, planning systems, and citizen participation across Europe. The scope includes capturing digital data of existing buildings using 3D laser scanning equipment and showing how this data can be used as an information base for enhancing the refurbishment process and maintenance. Furthermore, the paper discusses the state of the art for operating and maintaining facilities, describing the prevailing methods of building maintenance, highlighting their limitations with proposed alternatives, such as 3D Geographic Information Systems “3D GIS” to enable the spatial analysis and static visualisation of critical of query outputs and 3D laser scanning technology for obtaining the digital information of existing buildings for construction maintenance.

1 INTRODUCTION The new-construction market has been shrinking, while the renovation and refurbishment market is rapidly expanding in the construction industry (Mahdjoubi and Ahmed, 2004). Operating and maintaining a facility takes the biggest proportion of the lifecycle cost of a building. The growing emphasison lifecycle considerations through new forms of project

eWork and eBusisness in architecture, engineering and construction

42

relationships, together with the increasing refurbishment, retrofit and renovation of existing buildings (instead of new build) is bringing the role of the Facilities Management (FM) department to the forefront. Furthermore, previous research had shown that there would be no substantial change in aggregate demand for housing over the next decade (Simmonds and Clark, 1999). Therefore, organisations need to be able to quantify costs and communicate management information about their facility and infrastructure (Wix, 2003). To do this, they are turning to new information technologies to drive productivity gains. The most successfiil companies promote a free-flow of information between stakeholders. Typically, construction facilities require maintenance and occasional repairs on a regular basis, due to deterioration and aging. This is to keep them functional and in a satisfactory appearance. In fact, many organisations own a large variety of buildings and other types of constructed facilities, which need regular maintenance, occasional renovation and rehabilitation, and sometimes reconstruction of new facilities. Often, these organisations face a crucial dilemma, regarding the urgency and prioritisation of works and associated costs (Rosenfeld and Shohet, 1996). However, not many companies have utilised information technology to increase the efficiency of the refurbishment process for building maintenance. The above issues are addressed in the INTELCITIES project, which has a focus on the prevailing methods of building maintenance, highlighting their benefits and limitations. The paper also describes a proposed approach for the use 3D Geographic Information Systems ‘GIS’ and 3D laser scanning system, to enable the analysis and static visualisation of critical query outputs for building maintenance. 2 THE INTELCITIES PROJECT The INTELCITIES (Intelligent Cities) Project is a research and development project that aims at helping achieve the EU policy goal of the knowledge society. INTELCITIES project brings together the combined experience and expertise of key players from across Europe, focusing on e-Government, e-Planning and e-Inclusion, e-Land Use Information Management, e-Regeneration, Integration and Interoperability, Virtual Urban Planning, etc, (http://www.intelcitiesproject.com/). The overall aim is to advance the possibilities of e-Governance of cities to a new level through the development of a prototype of the IOSCP (Integrated Open System City Platform), as a clear and easily accessible illustration of a shared civic place in virtual space continuously available to all—whether officials, decision-makers and other professionals, such as planners, developers, politicians, designers, engineers, transport and utility service providers, as well as individual citizens, community groups/networks and businesses, through a wide range of interfaces. This paper focuses on the e-Regeneration work package of the project. The objectives of the package are to: 1. Produce a city vision for the post industrial city in the knowledge society and set of targets for systems to enhance regeneration. 2. Produce a system to support improved decision making about strategic planning of cities.

Virtual building maintenance

43

3. Produce a system to support development planning processes and that engage citizens in planning regeneration. 4. Show how these systems could be integrated with other city systems. 5. Report on how a holistic approach to all elements of building, refurbishment and urban planning and design can lead to successful, sustainable cities. The objective 5 specifically is addressed in the paper. The task, which is defined to achieve the objective 5, is the building data capture using the laser scanner technology and investigate this technology to enhance the refiirbishment process and maintenance. Figure 1 illustrates the vision, which is beyond the INTELCITIES project, for the use of 3D laser scanner for maintenance and refurbishment process. In the INTELCITIES project, the laser scanner technology is aimed at showing how it can be used for building refurbishment and maintenance. In figure 1, the first step centres on the creating VR models subject to the requirements of use and usage of the VR models such as building redesign and renovation, building survey and evaluation, reverse engineering, fabrication and construction inspection, health and safety, and urban planning and analysis. In the second step, integration is the main concern. Therefore, integration of the laser scanning system will be endeavoured with the GPS systems for linking the OS (Ordanance Survey) data or for linking the local authority data, with the GIS system for accomplishing the full integration of VR and GIS and with the Workbench for interactively analysing the VR models produced through laser scanning system.

Figure 1. Show how laser scanner technology can be used for maintenance and refurbishment process in the INTELCITIES project. In the third step, it is aimed at building data integration that is related to developing a conceptual model of nD modelling (Lee et al, 2003) system and associating it with the other data structures including relational databases and object-oriented databases to illustrate how data can be integrated to support intelligent city and construction systems.

eWork and eBusisness in architecture, engineering and construction

44

The rest of the paper considers DSS (Decision Support System) and delves into the integration of the 3D laser scanning technology with GIS system for building maintenance. In the next section, the existing methods of building maintenance and their limitations are explained in order to justify the integration of the 3D-GIS and the 3D laser scanner systems. 3 PREVAILING METHODS OF BUILDING MAINTENANCE AND THEIR LIMITATIONS Planning and control of building maintenance works are commonly performed using traditional media, such as paper-based plans and sketches. Other techniques have also emerged as decision support systems (DSS) and integrated environments. In recent years, major efforts were devoted to the development of decision support systems (DSS) to address building maintenance issues. Several of these systems have been developed to assist managers and decision-makers in planning building maintenance activities. Each DSS has its own functionality and designed for its unique purpose. These tools range from renovation design to initiation of renovation projects. Rosenfeld and Shohet (1996) have developed a unique DSS, which is capable of suggesting various building/facility-upgrading alternatives. This system was demonstrated on a 25-year-old dining facility in a military base that had suffered serious structural damage due to foundation problems. This system has proved valuable for the maintenance work. It provided managers with alternatives depending on the input criteria, including full descriptions of building evaluation and end-results. However, it only provides information on the general condition of the facility, including costs and subsequently life span of facility depending on how much money is available or what alternative is chosen. Underwood and Alshawi (2000) developed an integrated construction environment for the UK construction industry—the Simultaneous Prototyping for an Integrated Construction Environment (SPACE). MAINTenance ForeCASTing in an Integrated Construction Environment (MAINCAST) (Underwood and Alshawi, 2000) is an amplification of SPACE, which forecasts building element maintenance of a project as part of a fully integrated environment MAINCAST and was developed to assist the facility manager/owner (Client) in facility/project management by automatically generating detailed maintenance valuations, outlining the required maintenance during every operational year of the projects life, etc. However, these media suffer from several limitations. Firstly, it is difficult to identify the refiirbishment and renovation tasks. Secondly, it is also difficult to monitor the various tasks, because of the complexity of the operation tasks. The Rosenfeld and Shohet system DSS for instance is not capable of enabling managers and decision-makers to view the facility and see the damaged elements or locate them. Overall, the main limitation of these DSS systems is related to their output. They usually provide the results in a text format or tables and, in some cases, bar charts. This form of output is often not appropriate for decision-makers to visualise the results of their queries, especially when lay-clients are involved in the communication process. These tools have yet to adopt spatial analysis techniques such as GIS technology in their operation. A GIS enables the

Virtual building maintenance

45

spatial analysis and static visualisation of critical of query outputs (Enache, 1994) was critical of the failure of current DSS systerns to make use of advances in GIS technology. In addition, it does not allow them to visualise the final changes, before starting the maintenance work. Clearly, there is a need to improve the management of information and tasks about building maintenance. 4 3D-GIS AND LASER SCANNING TECHNOLOGY AS VR— EMERGING TECHNOLOGY OPPORTUNITIES Geographic Information Systems (GIS) are collections of computing techniques and databases that support the gathering, analysis and display of large volumes of spatially referenced data (USEPA, 2002). On the other hand, the innovation consists of a laser scanner controlled by a laptop computer. The scanner is targeted to the physical objects to be scanned and the laser beam is directed over the object in a closely spaced grid of points. By measuring the time of laser flight, which is the time of travel of the laser from the scanner to the physical objects and back to the scanner, the scanner determines the position in three-dimensional space of each scanned point on the object. The result is a cloud of points thousands of points in three-dimensional space that are a dimensionally accurate representation of the existing object (Schofield, 2001). This information can then be converted in a 3D CAD model that can be manipulated using CAD software, and to which the design of new equipment can be added. 3D Laser Scanner is currently used for a variety of sectors range from industrial applications for process automation in automotive industry, steel industry, robotics, etc, to mining, archaeology, survey, urban planning and railway, tunnel and bridge construction (Arayici et al, 2003). In recent years, however, the emerging GIS systems have presented organisations and management sectors with significant advances in making informed decisions. Ehler, Cowen, and Mackey (1995) argued that linking GIS with DSS systems has enabled the user to make well-informed decisions, based on the problem at hand. Also, Modis (2001) reported that tools, which are based on GIS technology, have ofFered managers and decision-makers substantial benefits, including usability, accuracy, and efficiency. Consequently, organisations around the world are reaping considerable benefits by capitalising on spatial technology solutions. GIS applications in (DSS) provide an enhanced means of resolving complex geo-analytical problems. Furthermore, systems based on 3D GIS technology are starting to supersede the early GIS systems (Jordan, 2000), (Song et al, 2002, 2003). Although still in its infancy, this emerging technology could clearly support the planning process of building maintenance projects. 3D modelling capability of GIS could also enable managers to foresee changes and modifications in an improved manner. However, despite the evident advantages of 3D technology to this type of planning and construction work, its fiill benefits could not be realised without an improved visualisation of the output. Indeed, the results of 3D GIS systems are usually displayed as a static cardboard model, which does not allow users to explore and rapidly visualise the results of their queries.

eWork and eBusisness in architecture, engineering and construction

46

Combining 3D GIS with advances in the Laser Scanner VR technology could provide decisionmakers more robust tools to visualise in real-time the 3D GIS environment. Verbree et al. (1999) argued that VR technology offers new and exciting opportunities to visualise 3D GIS data that, in turn, improve DSS usability and enable users to walk through 3D environments. It allows them to see building elements and appreciated proposed changes in a real time environment. Sidjanin (1998) demonstrated that linking GIS and VR oifered great capabilities for decision-making, as it could produce real-time and realistic visualisation of spatial data. In addition, VR interface could improve understanding of GIS spatial analyses and handling of queries on the data, as well as navigating through the dynamic map model and for using GIS functions. Similarly, the ability to rapidly sketch and visualise design ideas has been stressed as an important task in urban design (Smith, 1998). Hence the VENUE Project was conceived as a means of experimenting with links between GIS and 3D visualisation tools (ibid). The project demonstrated that a set of urban features can be visualised as building block outlines in 2D ArchView (based on Ordnance Survey base data). Removing building sub-divisions and line vertex generalisation enabled the production of 3D VRML (Virtual Reality Modelling Language) model by assigning a height attribute in ArchView. This approach is on a macro scale in relation to buildings but can be extended to a more detailed micro scale application suitable for building maintenance (Camara and Raper, 1999). In line with the foregoing, it can be established that there are several approaches that have successfiilly linked 3D-GIS with the Laser Scanner VR technology as a means of enhancing decision support. These successful developments further exposes the possibility of employing this combination to enhance current building maintenance DSS. The following section describes a proposed methodology, which is partly inspired by the work of (Mahdjoubi and Ahmed, 2004). 5 METHODOLOGY The aim of this section is to propose a framework which includes a series of analytical tools that will enable various stakeholders in the building maintenance sector to make informed decisions relating to building maintenance works. This framework, which is depicted in Figure 2, includes: 1) The development and population of a geo-spatial project database with the digital data of existing building captured with the laser scanning equipment. 2) The analysis of complex building information maintenance options within a knowledge repository environment, digital building data captured by the laser scanner is retrieved with 3D GIS system for the analysis. 3) The visualisation of the project information through a range of different interconnected graphic windows. The laser scanner VR model can be visualised in different platforms including workbench. The geo-spatial project database will describe the geometries of both the building frame and its components. Simple open geometric descriptions will be used, but each entry will

Virtual building maintenance

47

also be associated with data on inventory information such as name, supplier, date installed/replaced, number of previous replacements, etc. The procedure for the development will be based on establishing a robust objectoriented database management system (OOMS). The system will enable the capture of all geo-spatial information of the building frame and components using laser scanner. Inventory information relating to each frame and component will also be captured within the relational

Figure 2. The Virtual Building Maintenance System Framework. structure of the database. Such information will be accessible in real-time with some of the attributes (e.g. component supplier information) hyperlinked to the World Wide Web. Sequel to the development of the OODM, information captured will be linked to a knowledge repository developed purely for rule base and/or case-based interpretation of possible building maintenance schedules. This component of the VBM system will facilitate the generation of alternatives based on user-specified queries. GIS software will be used to generate and analyse thematic developments relating to the building properties and associated maintenance management strategies. ArcGIS 3D analyst, for example, enables users to effectively visualise and analyse surface data. Using the 3D spatial analysis capabilities of the tool, a range of possible scenarios of a building can be evaluated. Surfaces can be viewed from multiple viewpoints, queried, interrogated for visibility and viewed for the creation of a realistic perspective image. Furthermore, the evaluation can also be extended to display static images of building components that require immediate or 'near-future' maintenance based on the realtime information captured within the OODM and the knowledge repository. However, a final selection of the most appropriate software will be based on the most suitable representation (i.e. raster or vector) of the captured data. The VR environment will be developed using the laser scanner technology which also provides data models in different formats including the Virtual Reality Modelling Language (VRML). This approach is complimentary to previous work done on the information infrastructure developed through the OSCON, VIRCON and HyCon projects and the ongoing research for nD modelling project (Lee et al, 2003). Therefore, the results of the spatial analysis obtained within the 3D GIS environment can be evaluated

eWork and eBusisness in architecture, engineering and construction

48

in real-time with the options of viewing building maintenance alternatives developed from querying the knowledge repository. 6 BENEFICIARIES The research is of potential benefits and practical applications to the construction industry and professions. It will provide a better support for evaluation and visualisation of building maintenance works so that informed policies can be effectively targeted. It will benefit construction companies, facility and estate managers, and all those concerned with building maintenance issues. The ultimate beneficiaries of this work will be professionals and stakeholders of the construction industry involved with the: • building maintenance, • improved predictability of building maintenance requirements, • reduced maintenance planning and execution time, • increased safety, • Increased productivity.

7 SUMMARY This paper provides an overview of the e-Regeneration package of the INTELCITIES project, which aims at helping achieve the EU policy goal of the knowledge society. INTELCITIES project aims to bring together the combined experience and expertise of key players from across Europe, focusing on a number of built and human environment issues including e-Government, e-Planning and e-Inclusion, e-Land Use Information Management, e-Regeneration, Integration and Inter-operability, Virtual Urban Planning, etc, (http://www.intelcitiesproject.com/). This project recognises the need for integrating visualisation techniques and systems for building maintenance and refurbishment. In particular, the vision for the use of laser scanner equipment for building refurbishment and maintenance is addressed (see figure 1) and a framework for integrating such 3D GIS and Laser scanner systems is developed to assist the flow of information. Lastly, the beneficiaries of such integration are summarised. For the time being, the integration of 3D GIS and Laser scanner technology is being conceptually modelled. Once this is completed, it will be implemented. REFERENCES Arayici, Y., Hamilton, A., Hunter, G. (2003) “Reverse Engineering in Construction”, the conference of World of Geomatics 2003: Measuring, Mapping, and Managing, Telford, UK Camara, A.S., Raper, J. (1999) spatial multimedia and virtual reality. London, Taylor & Francis. Decision-Support Model. Application of the performance concept in building—International

Virtual building maintenance

49

Ehler, G., Cowen, D., Mackey, H. (1995) Design and Implementation of Spatial Decision Support System for Site Selection. ESRI, International User Conference, 1995, May 22–26, 1995, Palm Springs, (California), ESRI Enache, M. (1994) Integrating GIS with DSS: A Research Agenda. URISA Conference, Milwaukee, Wisconsin, August 1994 Jordan, L. (2000) Web Accessible 3D Viewing Next Step for GIS Virtualising the 3D Real World multi-view interface for 3D GIS. Computer & Graphics, 23, pp. 497–506. Lee, A., Marshall-Ponting, A.J., Aouad, G., Wu, S., Koh, W.W.I., Fu, C., Cooper, R., Betts, M., Kagioglou, M. Fisher, M. (2003) Developing a vision of nD-enabled construction, Construct IT, University of Salford, UK Mahdjoubi, L., Ahmed, V. (2004) “Virtual Building Maintenance: Enhancing Building Maintenance using 3D GIS and Virtual Reality (VR) Technology”, Conference of Designing, Managing, and Supporting Construction Projects through Innovation and IT solutions (INCITE2004), February 2004, Langkawi, Malaysia Modis (2001) IT Resource Management. (accessed on 28 November) Rosenfeld, Y. Shohet, I.M. (1996) Initiation of Renovation Projects: Techno-Economic Sidjanin, P. (1998) Visualisation of GIS Data in VR Related to Cognitive Mapping of Environment. IEEE Computer Society: conference on Information Visualisation, 1998, July, London: IEEE Computer Schofield, W. (2001) Engineering Surveying 5th Edition: Theory and Examination Problems for Students, ISBN 07506 4987 9 Simmonds, P., Clark, J. (1999) UK Construction 2010-future trends and issues—briefing paper Smith, A. (1998) The Venue Project: Adding 3D Visualisation Capabilities to GIS. Society, pp. 339–349. Song, Y., Hamilton, A., Trodd, N.M., (2002) technical Design Issues of Linking Geospatial technology for 3D Visualisation, Interaction and Analysis, in the Proceedings of the Conference on GIS Research in the UK, pp. 256–262. Song, Y., Hamilton, A., Trodd, N. (2003) Developing an Internet based Geographic Visual Information System, In the proceedings of the GIS Research in the UK 2003 Conference, 9th– 11th April 2003, City University, London. Underwood, J. Alshawi, M. (2000) Forecasting Building Element Maintenance within an Integrated Construction Environment. Automation in construction 9 (2000) pp. 169–184 Usepa (2002) GIS-Visualization (VIS) Integration Efforts. United States Environmental Protection Verbree, E., Van Maren, G., Germs, R., Jansen, F. Karaak, M. (1999) interaction in virtual world views-linking 3D GIS with VR. Geographical Information Science, 13(4), pp. 385–396 Wix, J. (2003) Domain/Facilities Management within the International Alliance of Interoperability, UK

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Supporting standard data model mappings R.W.Amor Department of Computer Science, University of Auckland, Auckland, New Zealand ABSTRACT: Very little work has been done on specifying a standard mapping between the overlapping semantic specifications in the standardized data models used in architecture, engineering and construction (A/E/C, e.g., IAI-IFC and ISO-STEP standards). However, several companies have developed bespoke mappings from these standards into their design tools, and back out again. With this approach it is difficult to understand how complete their mappings are, and what assumptions are made in the development Of the mappings. Yet for semantic mappings, as distinct from mappings over geometric representations, this has a profound implication for the correctness of the resultant data. In this paper the development of a suite of mapping support tools is discussed to illustrate the level of support required to ensure semantically correct mappings across data models.

1 INTRODUCTION 1.1 Problem statement The specification of a semantically correct mapping between any two standard data models used in the A/E/C industries is an enormous task. Data models have in the order of 500 entities and many thousands of relationships and attributes (e.g., IFC 2.x, IAI 2004). The mere task of sitting down and describing which entities are related to each other is daunting, let alone managing to encompass the full semantic coverage of the contents of each of these entities. Yet without some definition of a mapping to be implemented it is basically impossible to guarantee the correctness of any implemented translator for a standard data model. It is clear that human experts are needed to perform this task, knowledgeable in both schemas being mapped between. Yet even for such experts the management problem of describing a mapping over such large schema forces a requirement for some computerized support. This support comes in the form of notations and environments to specify what is equivalent between two schema in a form that can then be used to generate the code to actually perform the mapping. In the last decade there was an active research community developing approaches to mapping languages in engineering domains (Khedro et al 1996; Verhoef et al 1995; Eastman 1999: Chapter 11). Several of those efforts have been pursued in the development of the ISO mapping standard EXPRESS-X (Hardwick and Denno 2000), and in the development of mapping tables (ISO 1993). These mapping approaches are now being utilised on a wide range of standard data models available from ISO 10303 STEP, ISO 13584 Parts libraries and catalogs, CIS/2

Supporting standard data model mappings

51

(Crowley and Watson, 2000) and lAI’s IFCs (IAI 2002). However, every mapping between two of these standard data models will be duplicating the work of previous attempts. If it were possible to specify a mapping in an easily comprehensible manner, and there were tools that industry experts could use to agree on the correctness of the defined mapping, then a consensus on major mappings between schema could be developed and published in much the same way that standard schema are published today. This paper examines what tools would be required to reach this position. 2 A FRAMEWORK OF TOOLS To manage the task of developing a mapping between two data models there is a requirement for a range of support functions for the specifier. These include: • A graphical mapping notation to enable the specifier to visually comprehend the mapping being described between subsets of the data models. • A mapping specification environment to enable navigation through, and partitioning of, the space of mappings specified. Such a tool can also determine what has, or has not, been mapped between. • Automated mapping support to enable a significant proportion of the mappings required between two schemas to be automatically determined.

Figure 1. VML-G: a graphical mapping formalism. • A mapping interpreter to allow evolving mappings to be tested on partial sets of data. • A verifier to check the correctness of the developing mapping specification. Such a verifier would offer support from basic syntactic checking across the data models through to a more comprehensive semantic analysis of the proposed mapping. The development of such a support environment is described in the following sections. With this environment in place it is then possible to move on to providing standard mappings between the major standard schemas which exist in our domain.

eWork and eBusisness in architecture, engineering and construction

52

3 MAPPING NOTATIONS In order to describe the equivalences which exist between data structures in two different schema it is necessary to have a notation for the specification. A range of notations have been developed and utilised ranging from straight specification within a standard programming language (such as C or Java), through ISO mapping tables (ISO 1993), and the evolving ISO mapping language EXPRESS-X (Hardwick and Denno 2000). In many respects these approaches are analogous to the use of the EXPRESS language to specify the conceptual data structures for a schema for a particular domain. These approaches provide for a complete and detailed specification of how the mapping between portions of the schemas will have to be realised. However, they do not provide a way to gain an overview of the mappings which have been developed between two schema or the completeness of any particular mapping. Where schema have several hundred classes in them this is of major concern to the specifier. In the same way that EXPRESS-G is used as a high-level notation for describing the basic structures within a schema, and to view various subsets of a schema, a graphical mapping formalism will allow a high-level overview of the mapping between schemas to be presented. A range of graphical formalisms have been developed at the University of Auckland to represent mappings to different classes of users. Figure 1 shows a programmer level formalism for specifying mappings between UML styled class diagrams in two schema. The VML-G language (Amor 1997) shown in Figure 1 uses a wiring approach to denote a mapping between attributes, or classes, in a schema and an icon representing that particular mapping. The mapping icon provides three areas in order to separate general mappings between attributes and classes from the specification of invariants, which direct when the mapping is applicable, and initialisers, which describe starting values for particular attributes of a newly created object. As can be seen in Figure 1 the specification of the actual mapping is hidden from view and presented as a classification to either a straight equivalence (=), an equation (eqn), a functional equivalence (func), or a procedurally described equivalence (proc). By examining such a graphical mapping specification it is very easy to verify that all attributes are being handled in the mapping, and by examining the invariants across several mappings it is possible to verify that all possible conditions are being modelled. It also allows a high-level specification of the equivalences between portions of a schema without concentrating on the detail of how to achieve the mapping. The author contends that any textual mapping notation needs to be supported by a graphical formalism which allows for a high-level overview of the mappings which are being specified. 4 MAPPING SPECIFICATION ENVIRONMENT If a simple textual notation is used to describe a mapping then it can be developed in any textual editor. However, if a graphical formalism is going to be utilised to specify a mapping then it needs to be supported

Supporting standard data model mappings

53

Figure 2. A business level mapping specification environment. by a more comprehensive specification environment. Such a specification environment must allow for both graphical and textual notations to be viewed and the consistency between these views to be maintained under edits to either view. In Figure 1 the specification environment for VML-G allows for classes from the related schema to be viewed within a window, for a mapping icon to be placed in the window, and for wiring from attributes and classes to be drawn to the mapping icon. In this environment each window represents a particular mapping, and by navigating the various windows a specifier can examine the full set of mappings developed. The specifier can also switch to a textual view to see the full mapping specification and any edits made to the textual view are propagated back into the graphical view. From a programmer level support perspective this is very useful, but it does not tie to real data to help checking. In Figure 2 a business level specification environment is shown (Li et al 2002). Within this environment the schemas being mapped between are visualized as business forms and a wiring approach is used to specify the mappings between various fields in the forms. In this environment the specifier can view not just the data schema in a format close to its business use, but also exemplar data within each of the fields. Tied to this is

eWork and eBusisness in architecture, engineering and construction

54

the ability to run each of the partial mappings specified and hence to view the result of the application of the specified mappings in the other business form. 5 AUTOMATED MAPPING CREATION While the tools highlighted in Figures 1 and 2 clearly provide for greater comprehension and checking of the mappings which are being described it is also clear that detailing the mappings between schema which comprise several hundred classes is going to take a long time. In order to ease this workload it is useful to consider approaches which will allow for the automated specification of the mapping (or a portion of the mapping) between two schema. This is an area of ongoing research with many approaches being considered (see Rahm and Bernstein 2001 for a survey of approaches). This sort of tool is also useful to handle mapping between versions of particular product models. For example, the IAI have produced six versions of the IFC in the last seven years and the CIS/2 LPM is expected to be updated every year. The mapping between consecutive versions of a particular schema tend to be fairly minor which make for an easier problem when considering automated mapping creation. This problem is also closely related to that of schema evolution in object-oriented databases (Banerjee et al 1987, Lerner and Habermann 1990, Eastman 1992, Deux 1990, Zicari 1992, and Atkinson et al 2000). A previous student developed a hybrid mapper utilizing structure and name comparison to automate the creation of mappings for IFC versions (Amor and Ge 2002). This demonstrated that approximately 80% of

Figure 3. Voting in an automated mapping tool.

Supporting standard data model mappings

55

an IFC schema could be automatically mapped to the next version. An examination of points where this hybrid mapper failed illustrated that diiferent approaches to identifying mappings performed well in different settings. To explore how this might be utilized in automated mapping creation there has been a project (Bossung 2003) to develop an infrastructure to allow multiple matchers to vote on their proffered mapping for particular parts of an inter-schema mapping. Figure 3 shows a screen snapshot of this tool where three matching tools (a Levenshtein matcher, a partial name matcher, and a type matcher) bid for their mapping for a partial structure match. With this tool the user can examine the highest ranked mappings for any portion of the schema and select between the mappings being offered. Further work on this tool is looking at rematching mappings based on selections (changes) made by the user of the tool. 6 MAPPING INTERPRETER AND CODE GENERATOR In order that the specified mappings can be enacted it is necessary to generate code for each mapping. Within a tool which supports visualization of mapped exemplar data this has to take the form of an interpreter for individual snippets of the mapping. Every mapping tool must be able to generate the full mapping specification in some target language. With a high-level mapping specification language, as demonstrated in Figures 1 and 2, the mapping code generator allows for the creation of code in a number of target languages from bespoke languages such as VML (Amor 1997) and EXPRESS-X (Hardwick and Denno 2000) through to generic mapping languages such as XSLT and even straight into programming languages such as C and Java. 7 MAPPING VERIFIER As detailed in the introduction, developing a high-level mapping provides the specifier with a way to ensure that the semantics of the data in two schemas is going to match. However, due to the size of the schemas being developed this is still a difficult process. The provision of a graphical formalism helps in checking, as do support environments which map exemplar data based on the developing mapping. But, to ensure a correct mapping has been developed requires a comprehensive testing regime based around nontrivial exemplars. While the IAI and ISO do have a certification process and testing suites the approach is certainly not as rigorous as would be expected in a field such as software testing. The author suggests that the testing of a round trip mapping should be considered as the main form of verification for mapping specifications. While implemented translators for geometric models (e.g., DXF, IGES, etc) are known, and assumed, to have errors this is not such an issue as human interpretation is used to determine the semantics of a translated geometric model. However, for an object-based model such errors are far more serious. A round trip mapping which does not preserve individual objects and their original parameters has changed the specification of the building to almost any tool which uses this data.

eWork and eBusisness in architecture, engineering and construction

56

8 CONCLUSIONS The development of mappings between two schema is a large and very important process when developing translators for the various standard schemas being used in the construction industries. To ensure correct specifications requires not just an expert in the various schema being manipulated, but also a range of support tools to help the specifier through the process. A range of these support tools have been developed and described briefly in this paper. However, to take the industry to the next stage where they can have confidence in the translators and mappings which exist requires that further rigor is injected into the mapping testing process. It is also recommended that a range of certified mappings be developed between the main “standard” schemas being developed for the industry as well as between the various versions of the schema which have been produced. REFERENCES Amor, R.W. & Ge, C.W. 2002. Mapping IFC Versions, Proceedings of the EC-PPM Conference on eWork and eBusiness in AEC, Portoroz, Slovenia, 9–11 September, 373–377. Amor, R. 1997. A Generalised Framework for the Design and Construction of Integrated Design Systems, PhD thesis, Department of Computer Science, University of Auckland, Auckland, New Zealand, 350 pp. Atkinson, M.P., Dmitriev, M., Hamilton, C. & Printezis, T. 2000. Scalable and Recoverable Implementation of Object Evolution for the PJama1 Platform. Persistent Object Systems, 9th International Workshop, POS-9, Lillehammer, Norway, 6–8 September,292–314. Banerjee, J., Kim, W., Kim, H. & Korth, H. 1987. Semantics and Implementation of Schema Evolution in Object-Oriented Databases, Proceedings of the 1987 ACM SIGMOD international conference on Management of data. San Francisco, USA, 311–322. Bossung, S. 2003. Semi-automatic discovery of mapping rules to match XML Schemas, Department of Computer Science, The University of Auckland, NewZealand, 71 pp. Crowley, A. & Watson, A. 2000. CIMsteel Integration Standards, Release Two, 5 Volumes, Steel Construction Institute and Leeds University, UK. Deux, O. 1990. The story of O2. IEEE Transactions on Knowledge and Data Engineering (TKDE), 2(1), March, 91–108. Eastman, C.M. 1999. Building Product Models, CRC Press, Orlando, FL, USA. Eastman, C.M. 1992. A data model analysis of modularity and extensibility in building databases, Building and Environment, 27(2), 135–148. Hardwick, M. & Denno, P. 2000. The EXPRESS-X Language Reference Manual, ISO TC184/SC4/WGH N117, 2000–06–28. IAI. 2002. International Alliance for Interoperability, web site last accessed 18/6/2004, http://www.iai-international.org/. ISO 1993. Guidelines for the documentation of mapping tables, ISO TC184/SC4/WG4 M105, 1993–09–10. Khedro, T., Eastman, C., Junge, R. & Liebich, T. 1996. Translation Methods for Integrated Building Engineering, ASCE Conference on Computing, Anaheim, CA, June. Lerner, B.S. & Habermann, A.N. 1990. Beyond schema evolution to database reorganization, Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), Ottawa, Canada, October, 67–76.

Supporting standard data model mappings

57

Li, Y., Grundy, J.C., Amor, R. & Hosking, J.G. 2002. A data mapping specification environment using a concrete business form-based metaphor, In Proceedings of the 2002 International Conference on Human-Centric Computing, IEEECS Press, 158–167. Rahm E. & Bernstein, P.A. 2001. A survey of approaches to automatic schema matching, The International Journal on Very Large Data Bases (VLDB), 10(4), 334–350. Verhoef, M., Liebich, T. & Amor, R. 1995. A Multi-Paradigm Mapping Method Survey, CIB W78—TGIO Workshop on Modeling of Buildings through their Life-cycle, Stanford University, California, USA, 21–23 August, 233–247. Zicari, R. 1992. A Framework for schema updates in an object-oriented database systems. Morgan Kaufmann Series In Data Management Systems, 146–182.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Virtual building environments (VBE)— applying information modeling to buildings V.Bazjanac Lawrence Berkeley National Laboratory, University of California, Berkeley, CA, U.S.A. ABSTRACT: A Virtual Building Environment (VBE) is a “place” where building industry project staffs can get help in creating Building Information Models (BIM) and in the use of virtual buildings. It consists of a group of industry software that is operated by industry experts who are also experts in the use of that software. The purpose of a VBE is to facilitate expert use of appropriate software applications in conjunction with each other to efficiently support multidisciplinary work. This paper defines BIM and virtual buildings, and describes VBE objectives, set-up and characteristics of operation. It informs about the VBE Initiative and the benefits from a couple of early VBE projects.

1 INTRODUCTION Most manufacturers thoroughly test their products before delivering them to the market. In some industries the testing is done on physical prototypes, in other it is done virtually; in many industries it is done both ways. Manufacturers know exactly how their products are going to perform or hold up before these products are built and sold. For example, car manufacturers extensively test prototypes (both virtually and on the track) and know how the new models will perform before they start manufacturing them, even if they do not disclose all information in public. NASA thoroughly tested all new space vehicles in the Gemini, Apollo and Space Shuttle Programs in simulation and launched them only after all problems were proven in simulation to have been solved; when unforeseen problems developed later (such as during the Apollo 13 mission), NASA was able to analyze and resolve problems in simulation. In most developed countries the buildings construction industry, sometimes called the Architecture-Engineering-Construction-Operations (AECO) or Architecture-EngineeringConstruction-Facilities Management (AEC/FM) industry, is the second largest industry. Yet, virtually no testing of the primary product of the industry—the building—is done before irrevocable and often very costly decisions are made. True, pre-manufactured components are often tested at least in some ways before delivery; mock-ups of critical parts of a building are built and tested at times; various types of the building’s performance are occasionally simulated; and extensive visual simulations (including “walk-throughs” and “fly-bys”) are becoming the norm. But no testing of the whole building in all of its aspects of performance is performed before the building is delivered. Commissioning constitutes only a partial substitute for testing and is of little help if the

Virtual building environments

59

building in question needs substantial redesign and/or reconstruction to perform as originally expected. The product conception-construction-delivery process in most other industries follows the “designtest/verify-manufacture-deliver-warranty” script In contrast, the AECO industry seams to employ the “convince-build-pray” modus operandi. The designers convince the client by demonstrating a few selected performance aspects (usually cost and image) he/she can understand—but the designers cannot guarantee—that the building will work to the client’s expectations; the builders build the building, and then everyone awaits to see how the building will work once it is occupied and in use. They hope for the best, but fear the worst. At best, everybody is eventually relieved (even if some feelings have been hurt in the process); at worst, almost everybody involved faces legal consequences. Given that the “standard of practice” for how buildings are procured and delivered has not substantially changed in more than a hundred years, no other modus operandi can really be expected. Most (building design) decisions are made without testing their effect first. Whatever testing takes place in the design and construction phases is limited to only a few aspects of performance (i.e. it is intended to aid only specific types of decisions); it is infrequent and usually lacks follow up. It is slow and often delays the building procurement and delivery process it is expected to expedite. It is often very costly and is seldom required, or even accounted for, in contracts. Obviously, tests and comprehensive verification of performance are very difficult to attain when each product is essentially a very costly “one of a kind,” and when it takes a long and laborious multidisciplinary effort to design and build it. It does not help that the product is also very complex and complicated, and that smaller scale partial replicas can reproduce only a few of the performance aspects of the product, and even those mostly only as approximations. In similar situations, decision makers in other industries use software that can simulate the product’s performance that is of interest—they build virtual products they can experiment with and test with computers. It is clear that the AECO industry will be able to test its product (i.e. buildings) in a comprehensive manner only virtually—it will have to first build virtual buildings, test them (and make the necessary design and planning modifications) and physically construct them only after that. The industry has been using industry specific software more than just occasionally for about 20 years, ever since the first versions of AutoCAD appeared on the market and in schools of architecture and engineering. Today, industry use of software extends well beyond CAD with “downstream” applications that model performance relevant to or resulting from different parts of a building’s life cycle. However, unless they belong to an integrated suite of software tools, these applications have little to do with each other— they are “unaware” of each other, often describe essentially same data in different ways, and do not exchange or share data. This is resulting in an unnecessary generation of duplicate data, and is causing a lot of unnecessary errors and omission, cost and delays (Bazjanac 2001). The creation of virtual buildings and their productive use in experimentation and testing will require additional software and, more importantly, organized coordination among all software that may be used. Some leaders of the AECO industry have realized this and have formed a slew of new organizations and consortia in the last decade

eWork and eBusisness in architecture, engineering and construction

60

designed to bring “new technology” and “software interoperability” to the industry. These include the International Alliance for Interoperability (IAI 1995), the Building Lifecycle Interoperable Software consortium (BLIS 2000), the Continental Automated Buildings Association (CABA 2002), FIATECH to “bring technology to capital projects” (2002), the Construction Users RoundTable (CURT 2003), the Open Standards Consortium for Real Estate (OSCRE 2003), to name just a few in North America. Perhaps one of the most important of these to date is the IAI, because it developed the Industry Foundation Classes (IFC), the first open object oriented comprehensive data model of building that provides rules and protocols for definitions that span the entire life cycle of a building. IFC are also the only such model that is an international standard (ISO/PAS 16739). All major CAD vendors have developed their internal “intelligent” data models of buildings; these are designed to support the work of and data exchange within a particular vendor’s suite of tools and are thus limited in scope, are dissimilar and proprietary. Nonetheless, together with non-proprietary developments, these are all beginning to move the users of industry specific software from defining buildings as sets of lines and text that must be interpreted by the observer to defining buildings as information models. Definition of buildings as information models will be the foundation in creating virtual buildings with software that can seamlessly access data from the information model, manipulate/use them, generate new data, and return them to the information model. 2 DEFINITIONS: BUILDING INFORMATION MODELS AND VIRTUAL BUILDINGS 2.1 Building information models Building information modeling (BIM), used as a verb, is the act of creating a Building Information Model (BIM—a noun). While it was apparently a term originally used by Autodesk staff internally, Jerry Laiserin was the first to widely publicize it in the industry (Laiserin 2002). Used as a noun, a BIM is an instance of a populated data model of buildings that contains multidisciplinary data specific to a particular building which they describe unambiguously. It is a static representation of that building (i.e. it uniquely defines that building in a section of time)—it contains “raw” data that that define the building from the point of view of more than one discipline. Data contained in a BIM are also “rich:” they define all the information pertinent to the particular building component. A threedimensional “surface” model of building geometry alone that is used only in visualization is usually not a BIM. A BIM includes all relationships and inheritances for each of the building components it describes; in that sense it is “intelligent.” A data set that defines only a single “view” of a building (i.e. that describes a specific single type of performance), such as a data set that, for example, includes all data a structural engineer may need for structural calculations (but nothing more) is, by itself, not a BIM.

Virtual building environments

61

2.2 Virtual buildings A virtual building is a BIM deployed in software. It simulates the behavior or performance of a building or building component(s) entirely within a computer system, without any physical construction of the building or any of its components. A virtual building constitutes the use of data that are contained in a BIM to reproduce the behavior or performance of a building or building component(s) with accuracy appropriate to the reason for reproduction. The BIM is deployable by a suite of software that can reproduce behavior or performance in a comprehensive way and, as appropriate, over time. A virtual building is a dynamic building representation, even if a particular single “view” of the building is static. Any software that can access and use data contained in a BIM to simulate some form of behavior or performance of the building can be part of a virtual building software suite. Different software within the same suite can depict behavior or performance at different levels of detail, as long as each is appropriate for the “view” it represents. The software is operated by qualified professionals who are experts in both the use of a particular software application that is part of that suite and in the industry discipline that application belongs to. Virtual building operators need this dual expertise to properly resolve or interpret issues that arise from limitations of software, lack of reliable data and/or professional conventions. 3 DATA DEPOSITORY AND ACCESS ISSUES It takes an enormous amount of data to define everything even in small and “simple” buildings. The amount of data to describe a building increases manifold with increase in building size and complexity. The temptation to reduce the amount of data by discarding data in which one has no interest is countered by the realization that each datum is potentially of interest to someone else. As explained above, a BIM contains data that define building status in section of time. To reduce the physical size of a BIM, instead of replicating data available externally (such as manufacturers’ product data for some of the building components), it only includes pointers to external data bases where such data are available. In the case when a building definition depends on results generated by a software application, instead of capturing the entire (usually large) submission from that software, the BIM contains only data that enable the regeneration of the submission (i.e. the BIM captures only the data needed to reproduce the input for that software). Virtual buildings generate enormous amounts of data on their own. These are measured and/or simulated time based data that are critical to the definition of building behavior and performance. When used in a virtual building, a BIM also includes pointers to data bases that keep such data externally. The shear amount of data that define a building can pose problems in data exchange. Standard file exchange is impractical when the file includes a complete BIM. Model servers which facilitate partial model exchange (i.e. exchange of only some of the data) can solve that problem: The (very large) BIM file is resident in a model server, and

eWork and eBusisness in architecture, engineering and construction

62

“clients” query for and extract only data needed by a particular application. The extracted data, given proper authorization, can come from any part of the BIM: a specific individual datum or data sets that represent a particular “view” (or a set of “views”) of the building. Depending on the location of the model server, the data can be accessed directly or via web services. File exchange usually requires implementation of the same version of the building data model by both the generating and receiving software. Data model versioning is typically irrelevant to model servers. 4 VIRTUAL BUILDING ENVIRONMENTS Despite recent eiforts by the leading CAD vendors and the new industry organizations to promote building information modeling as the way to define buildings, an overwhelming majority of building procurement projects is still done the same “old way” by defining and representing buildings in “dumb” 2-D and text documents and with little, if any, use of contemporary IT technology. This is true even though technology exists now that can make professional work in most of the industry disciplines much more efficient and effective than it is today. The industry in general is resisting efforts to change toward information modeling and creation and use of virtual buildings. The causes for this resistance are found in several pragmatic reasons: steep learning curves, lack of time and adequate funding, and shortcomings of software. Most software applications that are specific to the AECO industry share a common characteristic: Their proper use requires intricate knowledge of the application and expertise in the corresponding industry discipline. Obtaining such level of knowledge and expertise for all industry software that is used for a given project is very difficult and often prohibitively expensive. End users that have the task to create a “real life” project BIM and use interoperable and non-interoperable software with it can face very steep learning curves and software that is sometimes at best in beta status and cannot easily do what the user expects it to do. They are under pressure to meet tight “regular” deadlines, and seldom have any meaningful additional resources to do their work on a given project in a way different than before. After briefly trying information modeling, their typical response is: “This does not work (for me/for this project/for my office/at all).” They then revert to the “old ways” of working and using “dumb” software. Often overlooked is the impact of the “old way” of procuring buildings on multidisciplinary teams that are assembled to work on a given project. As currently practiced, their work is unnecessarily difficult: Communication is far from efficient, data exchange is costly and ridden with errors and omissions, data sharing is not practiced and is often practically impossible, and their work is “behind schedule” almost by definition. In addition, their group experience and knowledge is seldom reused in another project and is usually lost after the project is over. The work of multidisciplinary teams could become much more efficient and effective with the use of BIM and virtual buildings. BIM development and the use of virtual buildings today usually require help. This help is now beginning to be available in the form of Virtual Building Environments that are designed to assist end users of industry software and serve as a “break through”

Virtual building environments

63

mechanism to get building information modeling and virtual buildings deployed in the industry. 4.1 What is a virtual building environment? A Virtual Building Environment (VBE) is a place where a group of industry software is operated by industry experts who are also experts in the use of that software. The primary purpose of a VBE is to facilitate expert use of appropriate software applications in conjunction with each other. A VBE employs software applications that, as a group, define a building, its parts, its behavior and its performance. It involves simultaneous or near-simultaneous simulation and display of data generated by multiple sources. A VBE facilitates the manipulation of data that are used in the planning, design, construction and operation of a building. It makes it possible to conduct experiments on the building or its parts, without first erecting them. In summary, a VBE is a physical place (i.e. a location) that facilitates expert creation of and use of virtual buildings. Ideally, a VBE follows a building’s entire life cycle, and the selection of software changes correspondingly from that related to design, to that related to construction, to that related to commissioning, to that related to operation and maintenance, and eventually to that related to demolition. The selection of software and participating experts supports broad definitions of design, construction and operations. For example, the construction and maintenance processes can be planned and modeled along with the building itself to evaluate constructability and maintainability early in a project. Similar to a selected group of software, a VBE involves a group of experts. Group members have the experience, expert knowledge and skills in both software applications and industry disciplines the software is related to. They understand the relevance, the meaning and the quality of data used in a particular industry project, as well as the implications of decisions made in the use of software. They can solve problems and define tasks appropriate to specific applications, and can create “work-arounds” within a particular application if the application cannot deal with the problem or data as defined. When a VBE is employed in a specific industry project, the group of experts contains those that have expertise, knowledge and skills relevant to the particular project. From the VBE perspective this group of experts is temporarily extended (for the duration of the project) by staff or others from organization(s) that are working on the particular project or are involved with it. From the project perspective these experts join the project team temporarily to assist the team so it can more effectively use software needed for the project, create the BIM and test its designs, solutions and/or plans in a virtual building. 4.2 VBE objectives Other industries, such as automotive and aero-space, have reaped significant benefits from the use of IT. Virtual building environments should help experience and demonstrate explicit benefits from the use of contemporary IT in the building procurement process: the use of groups of software to solve multidisciplinary problems, the use of comprehensive project data depositories that contain all project data (including historical), the automation and semi-automation of repetitive tasks, prompt access to expert knowledge, instantaneous distribution of complete data sets to all who need them,

eWork and eBusisness in architecture, engineering and construction

64

seamless and instantaneous multi directional exchange or sharing of interdisciplinary project information, virtual collaboration, concurrent engineering, and much more. They can provide support to many different types of industry projects that can benefit from the use of virtual buildings. These, among many other, include architectural, engineering and interior design projects to test design alternatives, refine decision, control building cost, and explain and communicate results; new construction and reconstruction projects to foresee and prevent problems in construction and its sequencing, detect insufficient or missing information, and test and explain cost effective substitutions and/or deviations from design documents and specifications; energy conservation projects to test alternatives in heating, cooling and illuminating a building, as well as alternative building energy management strategies; in building security and safety training to explore “what-if” scenarios, prepare first responder teams to provide most effective response in different emergency and disaster situations, and to test different response plans; in capital facilities projects to minimize risk to owners and operators by providing much more complete and reliable information about a given building’s design and construction and its operation throughout its life cycle. A VBE can be described as a “resource center” or a “center of excellence” that can serve as: (a) an industry specific software deployment center for industry projects (b) a center of education, and (c) a knowledge and technology development center 4.2.1 Software deployment center for projects As a software deployment center a VBE provides immediate expert help in the use of established and new industry software. VBE experts can help industry project staffs select the right software for the project, “hold (their) hands” (i.e. demonstrate how to use the software to accomplish specific tasks) as they start using the software, and advise them in the selection of proper choices they may make in the use of software. Some of the industry software on the market today is still in initial stages of maturity. Such software cannot successfully perform all of the tasks end users expect it to perform, or it cannot perform its tasks if a building is unusual (i.e. not trivial), complex, complicated or large. VBE experts can find ways around some of these problems (i.e. develop “work-arounds”) and report specific software shortcomings and its causes directly to software developers, so software can be improved. In that way a VBE can become an important factor in making industry software more mature and robust. Some of the interfaces of otherwise robust industry software to a data model (such as IFC) or other software may not work properly under all circumstances. VBE experts can detect and identify causes of such software interface problems and work with interface authors to correct them. Many organizations are hesitant to acquire costly new software their staffs do not know how to use, even if it is recommended to them for a specific project. A VBE provides an opportunity to use such software for the project without purchasing it, experience firsthand the benefits from using it, and learn how to use it before purchasing it. Thus a VBE can help spread and expedite the use of productive software in the industry.

Virtual building environments

65

4.2.2 Center of education A VBE provides opportunities to accumulate relevant knowledge and provides opportunities to share knowledge and learn. Few industry professionals have currently the knowledge and experience needed to operate groups of software at the level that is required when dealing with complex and complicated issues and problems. All too often project personnel are unable, hesitant or not in position to start learning on their own. A VBE provides opportunities to members of commercial design and engineering office staffs, construction managers, building operators and officials, code checking and enforcement officials, and others to create a BIM and operate a virtual building under expert supervision, as they are productively working on their project. This provides them with the initial experience of successfully doing that, which in turn may lead to the formation of an in-house partial VBE in their organizations. Industry-wide use of BIM-generating and virtual buildings software requires the support of professional consultants that are at ease with this technology. A VBE provides a framework to teach a new generation of such consultants by including them in the work on VBE projects (i.e. industry projects temporarily conducted at a VBE). It provides opportunities to consultants to join project teams and learn new skills (by participating, without compensation, in the work on such projects) which they will then be able to competently offer to the industry. Professional industry workforce will have to develop additional skills that will enable it to effectively utilize the new technology in daily work. With very few exceptions, these skills are not taught systematically in today’s professional schools, and many of their graduates do not know or understand this technology and are ill at ease with it. The lack of faculty members at institutions of higher learning who are knowledgeable in this area of industry technology is one of the main reasons for that. A VBE provides opportunities to faculty on leave of absence to work directly on such projects, learn and assemble information needed for the development of new courses and curricula. 4.2.3 Knowledge and technology development center A VBE also serves as a center of knowledge that is needed to identify and solve problems that arise from the use of the new technology. These include problems encountered in information modeling of complex buildings, in massive or selective data exchange, in finding “work arounds,” and in support of newly emerging industry tasks, to name a few. A VBE provides a frame-work for research and development that will help software developers deliver more useful software. If not properly staged and controlled, intense exchange of project data can be actually counter productive. Issues of staging and control of industry data exchange are not yet well understood. A VBE provides opportunities to determine the proper sequencing between project information developed in different industry disciplines and that needed by software applications not in those disciplines. Without proper sequencing of data exchange, the use of some software may yield meaningless results. The limits of data exchange, data sharing and inter-operability among industry software are not clear at present. A VBE provides opportunities to explore and learn what these limits might be, and to explore and define ways of circumventing such limitations.

eWork and eBusisness in architecture, engineering and construction

66

As a technology development center a VBE provides talent to engage in limited software development when such development is needed and is not provided by the industry. When a group of critical industry software (i.e. “mission critical” software that is the primary software used in professional work of an industry discipline) would be well served by new middle-ware, the talent at a VBE may develop and disseminate such middle-ware. If a “mission critical” application lacks the interface to make it interoperable and its vendor cannot afford to develop it, a VBE may provide a framework to develop the interface. When manufacturers cannot agree on a common format for their products, a VBE may provide a framework to develop common product data bases for access by industry software. As need arises to make additional “mission critical” software interoperable, existing data models of buildings (such as IFC) will have to be extended to expand their fimctionality. A VBE may provide the necessary framework and expertise to develop and implement new data model extension schemata. 5 VBE INITIATIVE To promote the idea and stimulate the formation of virtual building environments, the Center for Integrated Facilities Engineering (CIFE) at Stanford University, Lawrence Berkeley National Laboratory (LBNL) and VTT (Technical Research Center of Finland) kicked off the VBE Initiative at the end of June 2002. The Initiative is an attempt to plan and create initial virtual building environments that will eventually spread worldwide expert interdisciplinary deployment of multiple industry specific software. Since most governments, with noted exceptions of those in Finland and Singapore, have shown little real interest and support to change how the AECO industry operates, the change will have to come from within the industry. The AECO industry will have to experience and learn the benefits from developing and using BIM and virtual buildings step by step, one project and project delivery staff at the time. It will have to learn how to improve the way it operates today. The VBE Initiative is a pragmatic strategy to start that process. The main goal of the Initiative is to propagate and operate virtual building environments, create a global network of Virtual building environments, and to promote opportunities these offer to AECO firms and organizations—opportunities to bring their “real life” projects to a VBE, to have VBE experts help their staffs do their project tasks more effectively, and to learn new things in the process, all at minimal (affordable) cost. Those who take advantage of these opportunities will have a chance to experience how to reduce professional and overall project delivery costs while increasing the value of their work and product, deliver the building sooner, or operate the building at a much lower cost with measurably fewer problems. To be able to properly support experts that are needed for the operation of a VBE, institutions that host a VBE need modest longer term funding not related to or coming from industry projects. Thus, another goal of the VBE Initiative is to stimulate seed funding for virtual building environments. The Initiative has several additional goals that may affect and change how the industry will operate in the future. These range from showing how to change and/or enhance

Virtual building environments

67

current industry processes to enabling industry soflware interoperability, and from providing help to “real life” industry projects to educating professionals. Some goals, such as assisting “real life” industry projects, are short term; others, such as helping educate new generations of professionals, are longer term. Because experts and talent needed to operate a VBE are still scarce, initial virtual building environments are by necessity hosted at academic institutions and research laboratories. If the VBE network is successful, the skill and expertise will gradually shift to the industry; the support virtual building environments can provide now will become less unique and the need for it will gradually diminish. With time, as the AECO industry in general becomes more skillful and trusting in the use of the new software and technology and effectively changes its work processes, the need to “hold hands” and assist project staffs, and to serve as centers of education may completely dissipate. 6 VBE PROJECTS The success of the Initiative so far has varied from country to country. The government in Finland established a VBE at the Tampere University of Technology, and the major Finnish property owner, Senaatti, has started several VBE pilot projects there. The Commonwealth Scientific & Industrial Research Organization (CSIRO) has started a number of pilot projects in Australia. Seed funding for virtual building environments has been developing very slowly in USA. The work of experts at quasi-VBE facilities is instead mostly fiinded from requests for specific expert service not otherwise available to the industry. In these cases the multidisciplinary work is typically limited to only a small number of disciplines and software (i.e. a small number of “views” of BIM), such as architecture, visualization, mechanical engineering and building energy performance simulation and assessment, or quantity take-off, construction process scheduling and visualization. Opportunities to provide effective VBE support will greatly increase in USA once a vendor supplies interoperable cost estimating software the results from which the industry can trust.

eWork and eBusisness in architecture, engineering and construction

68

Figure 1. Aurora II design alternatives A (top) and B, compared for construction and life cycle costs. (By courtesy of Jiri Hietanen of the Tampere University of Technology.) Still mostly in initial phases of development, existing virtual building environments seem to share a global characteristic: limited number of resident experts. By necessity, all virtual building environments in existence so far started “small,” offering VBE experts only in a few of industry disciplines. When needed, other VBE experts are hired as external consultants (if available); this increases the cost to the project and sometimes delays its progress. In June 2004, two years after the kick-off of the Initiative, its original authors organized a VBE workshop at Stanford University. The workshop showed that several pilot VBE projects are now in progress in different parts of the world. On two projects

Virtual building environments

69

that started earlier than others the first phase of work has been completed (both dealt with the schematic phase of architectural design). Aurora II VBE project at the Tampere University of Technology compared two design alternatives (Fig. 1) at the project development stage when conventional methods of analysis, based on schedules of spaces and some qualitative information from the building program, yield construction cost estimates expected to be within ±20% and life cycle cost estimates within ±25% of later actual costs. By creating virtual buildings for the two alternatives and discussing them simultaneously with the project client in an iRoom (a three-screen interactive workspace originally developed at Stanford University), VBE experts decreased the inaccuracy of the early construction cost estimate to within ±3% and the life cycle cost estimate to within ±5% (Laitinen & Hietanen 2004).

Figure 2. Glare test for a typical office in the e-Lab building using photometrically accurate lighting simulation. The VBE project for the e-Lab at the LBNL (Bazjanac 2002) used virtual building experiments to demonstrate various types of energy performance of typical office and laboratory spaces, as well as the building envelope. Using a suite of 10 different directly and indirectly interoperable simulation and visualization tools it showed in advance to the future occupants of these spaces and the client (US Department of Energy) how these spaces will fiinction (Fig. 2). 7 NEW JOB DESCRIPTIONS When CAD software started being embraced in the AECO industry some 20 years ago, it changed the nature of professional staffs in architecture and engineering. Offices replaced

eWork and eBusisness in architecture, engineering and construction

70

large numbers of “pencil and paper” draftspersons with fewer (albeit somewhat higher paid) CAD operators, who produced more drawings faster. This increased the volume of work and output per payroll unit and soon made offices who switched to CAD more competitive in the market. Information modeling and virtual buildings will inevitably change the office landscape once again. The most important new job position will be the Virtual Building Coordinator. This position will require substantial knowledge in modeling and software use relevant to the different industry disciplines that are part of that office’s business. Qualified candidates will be often hard to find and pricey; this role may have to be filled by special consultants. The CAD draftsperson will be replaced by a BIM modeler. This position will require skills in the use of computers and BIM authoring software. The current VBE experts will evolve into “high power” consultants: cost estimators, energy performance analysts, construction managers, etc. They will have the ability to determine the right course of action to resolve a specific project issue, modify and/or interpret information in external data bases, create “work-arounds” for software in their specialties, effectively communicate and explain information, and more. Another new job position will be that of a BIM keeper. Holder of this job will be responsible for the maintenance, safeguarding and administration of a BIM through the life time of the BIM. This position will require at least modest skills in information modeling and substantial knowledge of collaborative engineering. 8 PRESSING VBE ISSUES Some of the technical issues that surfaced in initial BIM authoring and the use BIM accessing software, such as data incompatibility, data model and software limitations, and problems in file based exchange, were reported earlier (Bazjanac 2002). It is now becoming increasingly clear that there are other major obstacles that are slowing down the process of moving toward industry wide use of information modeling and virtual buildings. These include poor quality of some of the BIM authoring and accessing software (that is buggy, immature and/or not robust), difficulties in reaching industry wide agreements in the definition of BIM “views” and/or in implementation of standard data model definitions in software, the small number of interoperable industry specific software, issues in data sequencing when populating a BIM, problems in managing different resolution of the same data as needed by different software, and more. The complete lack of aids for end users is glaring: there are no manuals, templates, case studies published in sufficient detail, nor anything else to guide a newcomer in the initial use of this technology. Missing also is a better understanding of measurable benefits from the use of information modeling and virtual buildings, and of ways to measure them. Recent work at CIFE (Fischer & Ju 2004) is beginning to address these issues.

Virtual building environments

71

9 CONCLUSIONS The AECO industry is finally beginning to use IT, BIM and virtual buildings more effectively. Virtual building environments are a strategy to spread the use of this technology throughout the industry. A VBE provides opportunities to organizations in the industry to get help: a structure (an organized way to do it), software, facilities and experts who can guide the work related to building information modeling and virtual buildings required by “real life” industry projects. It is now up to industry organizations to bring their projects to VBE centers and take advantage of these opportunities. The VBE Initiative represents the beginning of a global VBE network that will hopefully help the entire industry take advantage of the new technology. That will lead to different sets of industry processes, thorough testing before building, and (eventually) much better designed, built and working buildings. ACKNOWLEDGEMENTS The author wishes to thank Ari Ahonen from Tekes (the Finnish National Technology Agency), Prof. Martin Fischer from Stanford University, Jiri Hietanen from the Tampere University of Technology, Arto Kiviniemi and Tapio Koivu from VTT and Stephen E. Selkowitz from LBNL for their ideas and direct and indirect contributions in the formulation of virtual building environments. This work was partly supported by the Assistant Secretary for Energy Efficiency and Renewable Energy, Office of Building Technology, Building Technologies Program of the U.S. Department of Energy under Contract No. DE-AC03-76SF00098. REFERENCES Bazjanac, V. 2001. Acquisition of building geometry in the simulation of energy performance. In R.Lamberts et al. (eds), Building Simulation 2001, Proc. intern. conf., Rio de Janeiro, Vol. 1: 305–311.ISBN 85-901939-2-6. Bazjanac, V. 2002. Early lessons from deployment of IFC compatible software. In Ž.Turk& R.Scherer (eds), eWork and eBusiness in Architecture, Engineering and Construction, Proc. fourth Euro. conf. product process modelling, Portorož, SLO: 9–16. Balkema. ISBN 90-5809507-X. BLIS. 2000. Building Lifecycle Interoperable Software. http ://www.blis-proj ect.org CABA. 2002. Continental Automated Buildings Association. http://www.caba.org/ CURT. 2003. Construction Users Round Table. http://www.curt.org/ FIATECH. 2002. http://www.fiatech.org/ Fischer, M. & G.Ju. 2004. Case studies of the implementation and valuation of Virtual Building Modeling (VBM). CIFE SEED project (in progress), Stanford University. http://www.stanford.edu/~fischer/ VBECIFE0604 IAI. 1995. International Alliance for Interoperability. http://www.iai-international.org/ Laiserin. 2002. Comparing pommes and naranjas. The LaiserinLetter(tm). Issue 15. http://www.laiserin.com/

eWork and eBusisness in architecture, engineering and construction

72

Laitinen, J. & J.Hietanen. 2004. Aurora II project. VBE workshop. Stanford University. http://www.stanford.edu/~fischer/ VBECIFE0604 OSCRE. 2003. Open Standards Consortium for Real Estate. http://www.oscre.org/

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

A persistence interface for versioned object models Daniel G.Beer1, Berthold Firmenich2, Torsten Richter1 & Karl Beucke1 1 Informatik im Bauwesen, Bauhaus-Universität Weimar, Germany 2 CAD in der Bauinformatik, Bauhaus-Universität Weimar, Germany ABSTRACT: Object models of current planning applications are very complex, huge and individually structured. Complexity increases, if they are versioned for distributed processing. Such models have to be made persistent. This paper proposes a persistence concept for such purposes. The concept is independent from a specific persistence schema and database. For a pilot implementation alternatives are discussed briefly and a specific persistence schema for a chosen database are described.

1 INTRODUCTION 1.1 Distributed processing of common planning material The distributed synchronous and asynchronous processing of a common planning material is in the focus of current research (DFG 2004). New publications in the field of CAD show concepts for the distribution of the planning material abstracted as objects and object versions (Firmenich 2002): Work starts by loading a valid structured subset of object versions from a common project in the planner’s private workspace (Beer & Firmenich 2003). Object versions of the workspace can be modified or deleted and new object versions can be created independently from the project and the network with the help of an integrated planning application (Beer et al. 2004). At the end of the work (long transaction: from hours up to days) object versions are stored in the common project. Operations to ensure consistency are described in (Firmenich 2002). A corresponding system architecture for the distributed processing is shown in Figure 1. It is based upon a project—workspace approach. 1.2 Objective and content The unversioned model of the planning application has to be stored into (loaded from) the persistent model of the common project. The second section describes the general stmcture of object oriented planning application model. This is the base for the persistence mechanism. Requirements on the persistence mechanism are deduced.

eWork and eBusisness in architecture, engineering and construction

74

Figure 1. System architecture for the distributed processing. The persistent model of the project will be described in the third section. Versioning and the selection of subsets that influences the persistence schema have to be considered. Possible persistence schemas and data stores will be discussed and compared with each other. A suitable persistence schema and data store is chosen for a pilot implementation. The description of the persistence layer and a pilot implementation in the fourth section concludes this contribution. 2 MODEL OF THE PLANNING APPLICATION 2.1 Object types and structuring The model of a planning application is very complex. There are many objects representing a lot of elements of a complex building. These objects are instances of a wide range of classes as we can see for example in the IFC model (IFC 2004). This huge variety of classes also results from different planning applications for specific planning tasks involved in the common project. Thus, the objects are structured diversely. It is not certain that all applications use a common labelling and it can not even be assumed that there is one.

Figure 2. Types of object attributes.

A persistence interface for versioned

75

2.2 Versioning Most planning applications do not support versioning. The workspace manages an unversioned model to use such applications. The transformation between unversioned model of the workspace and versioned model of the project is described in (Beer et al. 2004). 2.3 Attributes As shown in Figure 2, objects (a) can have attributes of different types: – Atomic values (f1) can not be decomposed anymore. Examples are strings or numbers as well as objects that can be represented by strings, for example dates. – Objects (f2). There is a 1:1 relation to another object (b). – (Un)ordered sets of objects (f3). There is a 1:n relation to other objects belonging to a set (s). – (Un)ordered relations of objects (f4). There is a 1:n relation to object tuples belonging to a relation (r). To reduce complexity, only binary relations are considered in this contribution. Relations of higher order can be treated analogously. 2.4 Inheritance Objects can inherit attributes from a super class. This has to be considered if objects extending a super class have to be made persistent. 3 PERSISTENT MODEL OF THE PROJECT 3.1 Versioning Each object of the planning application model is stored as an object version in the common project (Beer et al. 2004). The mathematical foundations of this model are described in (Firmenich 2002). An example is given in Figure 3.

eWork and eBusisness in architecture, engineering and construction

76

Figure 3. Versioned model of the project (example). Object versions (a4, b2) are elements of set M. The version history is stored as ordered pairs of object versions ((a2, a4)) in the relation V. Dependencies between object versions are stored as ordered pairs of object versions in relation B. These three sets can be interpreted as a graph. The version history is shown by dashed arrows, the dependencies are shown by continuous arrows. 3.2 Subsets A uniform access to differently structured objects is needed for the selection of subsets from the project model. Therefore the native attributes should be used as the least common base of all objects. As shown below (see Subsection 4.2) an object wrapper can unify attributes with a common semantics. A set algebra respectively a language is a flexible and easy way to describe subsets (Beer et al. 2003). The feature logic (Zeller 1997) is a set algebra that uses attributes or so called features. Thus, feature logic is well qualified to be used for object access via attributes. Table 1 shows important operations that are partially based upon object’s attributes. 3.3 Persistence schema A persistence schema tailored to feature logic is given in (Firmenich 2002). The schema is shown in entity relationship notation in Figure 4. With the help of this schema, the operations shown in Table 1 can be implemented straightforward. Objects are stored as elements of a domain (domain). They are identified via a generated name. Atomic features are elements of the domain, as well. Values of atomic features are stored in Atom. Features are stored in Feature. The connection between object, feature and value is a relation of Relslot.

A persistence interface for versioned

77

The schema requires a decomposition of objects into object’s identifier (name), objecfs attributes and attribute’s values. Solutions for mapping objects to

Table 1. Feature logic operations. Operation

Symbol

Description

Extraction

f(S)

Value of the feature f of the object set S

Selection

f: S

Objects, whose feature f has the value S

Existence

f: T

Objects that have a feature/

Divergence

f↑

Objects that have no feature f

Agreement

f↓g

Features f and g have same values

Disagreement

f↑g

Features f and g have different values

Complement

~S

Complement of S

Union

Either R or S

Intersection

R∩S

R and S

Implication

R→S

If R then S

Equivalence

R↔S

Only if R then S

Term equiv.

R=S

Equality of R and S

Figure 4. Feature logic persistence schema.

eWork and eBusisness in architecture, engineering and construction

78

tables (Keller 1997) are known. They are discussed briefly and compared with the feature logic schema in the following. This is done for all supported attribute types (see Subsection 2.3). Generally, queries against the data store are generated from feature logic terms with the help of a interpreter (Richter et al. 2003). The feature logic persistence schema is tuned for that purpose. Thus, the user has to ‘speak’ feature logic, instead of formulating query expressions against the data store. Mappings for the different types of attributes, object versions and inherited attributes are discussed briefly and compared to the feature logic persistence schema in the following paragraphs. Advantages and disadvantages of the feature logic persistence schema are discussed in the last paragraph of this subsection. 3.3.1 Mapping of atomic attributes The feature logic schema is used for mapping atomic attributes (f) to tables: They are stored with their values (x, shown by a rectangular shape) as strings in different tables (Fig. 5). The feature ‘type’ stores the type of the object.

Figure 5. Mapping of atomic attributes.

Figure 6. Mapping of object attributes.

A persistence interface for versioned

79

3.3.2 Mapping of object attributes Example (Fig. 6): Object a has an object attribute h of type B with value b. There are different concepts for mapping object attributes respectively 1:n relations or so called references to tables: – Single table aggregation (Fig. 6a) (Keller 1997) Mapping: The attributes of the referenced object are stored in the same table as the attributes of the referencing object to avoid references. Advantages: Objects can be retrieved with a single table access. Disadvantages: Attribute values of multiple referenced objects are stored multiple. If the reference is deeper than one hierarchy step every change of referenced types causes an adaptation of all referencing types. A dot notation or a similar naming convention for the attributes of the referenced objects has to be used (for example h.g). Furthermore, it is hard to formulate queries using reference types. – Foreign key aggregation (Fig. 6b) (Keller 1997) Mapping: A separate table for referenced types is used. Object identifiers (b) link from the referencing to the referenced object.

Figure 7. Mapping of set attributes. Advantages: This schema is more flexible and better to maintain as variant a. Referenced objects can easily be queried. Disadvantages: A join operation or at least two database accesses are needed. It is difficult to achieve referencing from referenced objects. – Feature logic schema (Fig. 6c) (Firmenich 2002)

eWork and eBusisness in architecture, engineering and construction

80

Mapping: The mapping is similar to variant b. The difference is that all objects are stored in one table. Tables Atom, Domain and Feature are omitted in the example. 3.3.3 Mapping of set attributes A set includes a number of other objects (elements). An example is shown in Figure 7. There are different concepts for mapping set attributes to tables: – Foreign key association (Fig. 7a) (Keller 1997) Mapping: The identifier of the set is inserted into the set element table (attribute own). Advantages: The mapping schema does not collide with normal forms. Hence, it allows reasonable maintenance cost. The space consumption is nearly optimal. Disadvantages: Reading a set costs a join operation or two read operations. – Feature logic schema (Fig. 7b) (Firmenich 2002) Mapping: Set elements are represented by tupels (elmc, Fig. 7c) that are included in the set (s). They have a reference to the set element itself (c). The specific features ‘elm’ (element) and ‘in’ (included) are used. Sorted sets (sequences) are possible with the help of the specific feature ‘i’ (index). Tables Atom, Domain and Feature are omitted in the example. 3.3.4 Mapping of relation attributes A binary relation includes a number of pairs of other objects. An example is shown in Figure 8. The feature logic schema is used for mapping binary relations to tables: – Feature logic schema (Fig. 8a) (Firmenich 2002) Mapping: Elements of the relations are represented by tupels (elmru, Fig. 8b) that are included

Figure 8. Mapping of relation attributes.

A persistence interface for versioned

81

Figure 9. Mapping of object versions. in the relation. They have a reference to the elements (r and u). The specific features ‘in’ (included), ‘src’ (source) and ‘dst’ (destination) are used. Sorted relations are possible with the help of the specific feature ‘i’ (index). Tables Atom, Domain and Feature are omitted in the example. 3.3.5 Mapping object versions Object versions are part of the persistent model. An example shows Figure 9. The feature logic schema is used for mapping the version history to tables: – Feature logic schema (Fig. 9) (Firmenich 2002) Mapping: A revision (b2) of an object version (b1) is stored as the value of the specific feature ‘rev’ (revision). Tables Atom, Domain and Feature are omitted in the example. 3.3.6 Mapping of inheritance Objects can inherit attributes from a super class (Fig. 10). There are different concepts for mapping object inheritance to tables: – One table for one inheritance tree (Fig. 10a) (Keller 1997) Mapping: The union of all attributes of all objects in are used as columns of a single table. Null values represent unused fields in each record. Advantages: Reading/writing of base class descendants needs only one database operation. Schema evolution is straightforward and easy as long as the inheritance hierarchy does not become too deep.

eWork and eBusisness in architecture, engineering and construction

82

Figure 10. Mappingof inheritance. Formulating queries for all objects of the inheritance is fairly easy. Disadvantages: The waste of space depends on the inheritance depth. The deeper the hierarchy and the bigger the difference between the union of all attributes and the attributes of an average object, the bigger the waste of space. – One table for every class (Fig. 10b) (Keller 1997) Mapping: The attributes of each class are mapped to a separate table. An object identifier links derived classes with their parent. Advantages: The pattern provides a very flexible mapping. The space consumption is nearly optimal. Schema evolution is straightforward. Disadvantages: The mapping is performance expensive in terms of database operations. The costs rise with the depth of the inheritance hierarchy. Queries are hard to formulate as the mapping generally requires accessing more than one table. – One table for one inheritance path (Fig. 10c) (Keller 1997) Mapping: The attributes of each class as well as the attributes inherited from parent classes are mapped to separate tables. Advantages: The mapping needs one database operation to read or write an object. The space consumption is optimal.

A persistence interface for versioned

83

Disadvantages: A polymorphic scan of all objects given by their super class includes some tables. Inserting a new subclass means updating all polymorphic search queries but the structure of the tables remains untouched. Adding or deleting attributes of a super class results in changes to the tables of all derived classes. Queries are hard to formulate as the mapping generally requires accessing more than one table. – Feature logic schema (Fig. 10d) (Firmenich 2002) Mapping: The attributes of each class as well as the attributes inherited from parent classes are mapped to the same table. Tables Atom, Domain and Feature are omitted in the example. 3.3.7 Feature logic schema The feature logic schema was chosen for the pilot implementation. Advantages: – There is only one schema for all classes. It is independent from the typing. Thus, the schema is very flexible and easy to maintain. – There is no redundancy. The schema fulfils the requirements of the normal forms. – Objects can be used in different sets or relations with the help of tupel elements. They are stored only once. – Queries can be formulated very easy with the help of an extended feature logic (Beer et al. 2003). The query is transformed with the help of a database independent compiler (Richter et al. 2003). – References can be traversed via recursive queries (Price 2002). They are encapsulated by operations of an extended feature logic (Beer et al. 2003). Disadvantages: – Objects can be retrieved only via multiple table access. – Set and relation elements have to be loaded in a step after the set respectively the relation itself. This results in multiple queries. They may be optimised and executed as batches by the data store. 3.4 Data store Different types of data stores for a pilot implementa tion have been investigated. – Files/file system: The file input/output mechanism is relatively slow compared to RAM access. Furthermore, there are no adequate methods for queries on files. That is why file formats like XML are not qualified. – Relational database management systems (RDBMS) have been proven for commercial use and are technologically well established. They are well qualified for the use of mass data. RDBMS offer a very flexible and easy data access via a standardised query language (SQL). RDBMS can store relations in tables. Thus, the object oriented application model has to be mapped to the persistent relational model. The relational model corresponds with the feature logic persistence schema.

eWork and eBusisness in architecture, engineering and construction

84

– XML databases offer new concepts. They are very generic so that such databases are slower than relational database management systems. XML databases do not offer a better access to objects stored than RDBMS. – Object oriented database management systems (ODBMS). Currently available systems do not support the flexible selection of subsets with the help of a powerful query language. – Java Data Objects (JDO) is a persistence standard for Java objects. It defines interfaces that allow for data store independent persistency. Different types of data stores can be used depending on the commercial implementation that is used. However, the selection of subsets is limited. – Specific databases for engineering applications are in the focus of current research (Biltchouk & Pahl 2003). The objective is the straightly access to engineering objects. Such data stores may be used in the fiiture. A RDBMS has been used for the pilot implementation. 4 PERSISTENCE LAYER 4.1 Properties – Flexibility: Existing objects without persistency convention as well as new objects designed for this purpose are supported (see Subsection 4.2). – Independency: The persistency layer is independent from the data store used by a pilot implementation. The proposed system architecture (Fig. 11) shows interfaces and adapter classes that implement general fiinctionality. – Performance: Memory access is much faster than file system access. Furthermore, the storage of objects can be done in parallel with the running application so that the loading of objects has to be optimised. – Maintenance: The schema used is a very simple schema for all classes. That is why redundancy is no problem for maintenance. 4.2 Attribute access Objects to be made persistent have to publish all necessary attributes to be stored. Attributes have to be read for storing into project model and to be written for loading objects from the project model. There are different concepts for implementation: – Reflection: The programming language Java™ (Horstmann & Cornell 2002) offers a mechanism called reflection that delivers all public attributes. Private attributes can not be accessed. Objects can not be made persistent completely. Public attributes may not be sufficient to recreate the object.

A persistence interface for versioned

85

Figure 11. Persistence concept. – Interface: Objects to be stored have to implement an interface that defines methods for attribute access. This can be done in the source code (manually) or the compiled code. This is called source/ byte code enhancing. The mapping information has to be provided in a separate file (Jordan & Russel 2003). However, existing classes possibly must not be changed so that they can not implement an interface. – Conventions: Naming conventions, like JavaBeans™ for reusable software components, offer a standardised attribute and method access. However, most existing classes do not fulfil such conventions. – Wrapper: Classes that wrap existing classes and that fulfil a given interface are well qualified. The mapping between public attributes, attributes behind methods and persistent attributes is very flexible. Only those attributes needed to recreate an object have to be stored. They can differ from the object’s attributes and they can be named in a standardised way to have a common view on common attribute names. Specific attribute names outside a standard are possible, too. It is assumed that the persistence wrapper class returns the attributes of the wrapped class as well as the inherited attributes of its super class(es), too. For the access to the object’s attributes the wrapper concept in combination with the interface concept is used. Thus, it supports existing objects as well as new designed objects. Wrapper classes for all application defined classes implement a specific persistence interface PersistenceCapable (Listing 1, simplified: no exceptions, most important methods). The PersistenceCapable interface defines methods for the exchange of attributes and their values via strings. Thus, the type conversion is not a generic task of the database but can be done in the wrapper object individually. This increases maintenance because of the independency of the data types offered by the database used. Furthermore, the wrapper concept allows for a common structure of different structured objects.

eWork and eBusisness in architecture, engineering and construction

86

Standardised attribute names are possible by changing their original names (e.g. IFC conform names) as well as specific context dependent named attributes. interface PersistenceCapable { // Atomic properties Proplterator getAtomicProperties() ; void setAtomicProperty( String name, String value ); // Aggregations Proplterator getAggregationProperties() ; void setAggregationProperty( String name, String objID ); } interface Proplterator { // Iteration boolean iterate(); // Property information String getName(); Class getType(); Object getValueO ; boolean isChangeable (); }

Listing interface.

1.

PersistenceCapable

and

Proplterator

4.3 System architecture The persistence concept (Fig. 11) has three layers: The Atomizer, the PersistenceSchema and the DatabaseManager. They are managed by the PersistenceManager. The simplified interface is shown in Listing 2. The concept is independent from the persistence schema and the database used. A specific PersistenceManager class manages all persistence classes and instantiates specific classes for a specific schema anddatabaseused. Persistence-Capable classes can be registered to wrap existing objects (method registerPCClass). The PersistenceManager can store (a set of) objects and version relations (e.g. method storeObject) as well as load an subset of the persistent model described by a query (method load). The return values are persistent identifiers created by the project (case store) respectively pairs of persistent identifiers and associated objects (case load). Storing (a set of) objects the PersistenceManager calls the Atomizer’s decompose methods (e.g. method decomposeObject) to add the object information to the persistent schema managed by the Atomizer. The Atomizer (Listing 3) has the task of a serialiser. It decomposes the object graph into object types and attributes with atomic values. The object graph is traversed by

A persistence interface for versioned

87

object references (Fig. 2). Sets and binary relations are supported. They have to be distinguished because there are different container classes (Set, Map) defined by Java. A specific persistence schema is managed (method setPersistenceSchema). The created persistent identifier of already decomposed objects is used for all other references of this object. The Atomizer can store a schema (method store) and load a subset of the persistent model described by a query (method load). The return values are void (store) respectively pairs of persistent identifiers and associated objects (load). The class information is stored as the value of a specific feature type to instantiate the object. The Atomizer interface is implemented by the Atomizerlmpl class. interface PersistenceManager { // Registration void registerPCClass( Class pcCls, Class objCls ) ; // Persistence functionality String storeObject(Object o); String storeSet (Set s); void storeObjectVersionRelation( String PIDl, String PID2 ); Map load(String query); }

Listing 2. PersistenceManager interface. interface Atomizer { // Persistence schema void setPersistenceSchema( PersistenceSchema ps ); // Decomposition and storage String decomposeObject(Object o) ; String decomposeSet(Set s); void store (); // Loading and recomposition Map load(String query); }

Listing 3. Atomizer interface. The PersistenceSchema (Listing 4) is called by the Atomizer (e.g. method addObjectSchema) to store a specific type of attribute (Fig. 2) and create specific schema information (Figs 5–10). The schema can be stored (method storeSchema). Loading subsets from the persistent model described by a query a new schema is created (method create—Schema). Objects represented by the schema can be received via method getObjects. Attributes and attribute values for a specific object identified by the persistent identifier (objID) are returned by method getProperties. The PersistenceSchema is

eWork and eBusisness in architecture, engineering and construction

88

implemented by PersistenceSchemaAdapter class. For the used feature logic schema (Fig. 4) a specific class PersistenceSchemaFL was implemented. This allows for changing the schema used. interface PersistenceSchema { // Create schema from object tree String addObjectSchema(Class type); void addAtomicPropertySchema( String objID, String name, String val ); void addNonAtomicPropertySchema( String objID, String name, String vID ); String addSetSchema(Class type); void addSetElementSchema( String setlD, String elmlD ); void addObjectVersionRelationSchema( String PIDl, String PID2 ); // Store/ load schema to/ from database void storeSchema(); void createSchema(String query); // Schema information Set getObjects(); Map getProperties(String objID); }

Listing 4. PersistenceSchema interface. interface DatabaseManager { // Initialisation void init(String driver, String url, String user, String pwd ); // Reading from database ResultSet load(String sql) ; ResultSet loadBatch( String sql, StringU batch ); // Writing to database void store(String sql); void storeBatch( String sql, String[][] arguments ); }

Listing 5. DatabaseManager interface.

A persistence interface for versioned

89

The DatabaseManager (Listing 5) defines methods for accessing a database. The Database-ManagerAdapter implements relational database access. Specific classes (e.g. DatabaseManager-Oracle) support specific database access. 4.4 Pilot implementation The interfaces described above have been implemented. An ORACLE database and the feature logic schema are used.

Figure 12. Example: Object a to be made persistent. class PCA implements PersistenceCapable { // Attribute of type A private A a; // Object instantiation createObject () {a=new A (...);} // Atomic attribute access Proplterator getAtomicProperties() { return new Propertylterator () { int i=0; boolean iterate() {return i++
eWork and eBusisness in architecture, engineering and construction

90

Object getValueO { return a.getg(); } }; … }

Listing 6. Persistence wrapper for class A. 4.5 Persistence wmpper—an example It is assumed, that we have the situation described in Figure 12a: An object a of type A with atomic attribute f (value ‘v’), object attribute g (reference to object b) and set attribute h (reference to set s with objects c, d and e as elements) has to be stored. A wrapper class in particular for class A has to be provided (Figure 12b). The wrapper has to implement the PersistenceCapable interface and manage objects of type A to ask for attributes and create new instances as shown in extracts in Listing 6. Furthermore, the wrapper has to be registered at the project via the registerPCClass method of the project. A wrapper class can be multiply registered with several classes to manage these classes in common. ACKNOWLEDGEMENT The authors gratefully acknowledge the financial support of the project interCAD by the German Research Foundation (Deutsche Forschungsgemein-schaft—DFG) within the scope of the priority program ‘Network-based Co-operative Planning Processes in Structural Engineering’ (SPP 1103). We also want to thank the members of the working group ‘Distributed product models’ for the productive co-operation.

A persistence interface for versioned

91

REFERENCES Beer, Daniel, G. & Firmenich, B. 2003. Freigabestande von strukturierten Objektversionsmengen in Bauprojekten. In Digital Proceedings des Internationalen Kolloquiums uber Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (IKM). Weimar: BauhausUniversität Weimar. www.uni-weimar.de/ikm (17 May 2004). Beer, D.G.; Firmenich, B. & Beucke, K. 2003. Motivation fur eine Sprache zur Handhabung strukturierter Objekversionsmengen. In Kaapke, K. & Wulf, A. (eds), 75. Forum Bauinformatik: 128–135. Aachen: Shaker. Beer, D.G.; Firmenich, B.; Richter, T. & Beucke, K. 2004. A Concept for CAD Systems with Persistent Versioned Data Models. In Digital Proceedings of the Tenth International Conference (ICCCBE-X). Weimar: Bauhaus-Universitat Weimar. Biltchouk, I. & Pahl, P.J. 2003. Entwicklung einer Datenbasis fur Anwendungen im Bauwesen. In Digital Proceedings des Internationalen Kolloquiums iiber Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (IKM). Weimar: Bauhaus-Universität. DFG 2004. DFG priority program 1103: Network-based co-operative planning processes in structural engineering. http://www.iib.bauing.tu-darmstadt.de/dfg-spp1103/en/index.html (17 May 2004). Firmenich, B. 2002. CAD im Bauplanungsprozess: Verteilte Bearbeitung einer strukturierten Menge von Objektversionen. Aachen: Shaker. Horstmann, C.S. & Cornell, G. 2002. Core Java 2—Expertenwissen. Miinchen: Markt+Technik. IFC 2004. International Alliance for Interoperability: Industry foundation classes (IFC). http://www.iai-international.org/iai_international/Technical_Documents/iai_documents.html (17 May 2004). Jordan, D. & Russell, C. 2003. Java data objects. Beijing [u.a.]: O’Reilly. Keller, W. 1997. Mapping Objects to Tables. In Proceedings of Second European Conference on Pattern Languages of Programming (EuroPLoP ’97). Siemens Technical Report 120/SWl/FB. Munich: Siemens. Loney, K. & Theriault, M. 2001. Oracle 8i DBA-Handbuch. Miinchen [u.a.]; Hanser. Price, J. 2002. Oracle9i JDBC programming. New York [u.a.]: McGraw-Hill/ Osborne. Richter, T.; Firmenich, B. & Beucke, K. 2003. Ein Java-Paket zur Verarbeitung von Datenstrukturen in beliebigen Datenquellen. In Kaapke, K. & Wulf, A. (eds), In 15. Forum Bauinformatik: 136–146. Aachen: Shaker. Zeller, A. 1997. Configuration Management with Version Sets—A Unified Software Versioning Model and its Applications. Braunschweig: Fachbereich Mathematik und Informatik.

eWork and eBusiness in Architecture, Engineering and Construction—Dikba§ & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Semantic parameterized interpretation: a new software architecture for conceptual design systems A.Eir Informatics and Mathematical Modelling, Technical University of Denmark ABSTRACT: Class-based CAD systems make the majority of systems for building design. However, such systems lack of dynamics in two respects: Objects cannot be specialized incrementally, and introducing new classes or properties requires code restructuring and recompilation. The two sorts of dynamics are, however, attractive as they are necessary to support incremental design. The present paper suggests a new software architecture which offers the two kinds of dynamics. It does so by understanding the design system as an interpreter of conceptual models. In these models, free terms can be introduced when these are needed for expressing the current design. The meanings of the terms are defined in a semantics which becomes a parameter to the interpretation mechanism. The result of an interpretation is a certain perspective – a view – on the model. Such a view can be a representation of visualisation, equations for stress analysis, or other information derived from the model.

1 INTRODUCTION The introduction of object-orientation has had a tremendous impact on the foundation and software architectures for computer aided design systems (CAD systems). Such systems are today mostly object-oriented and founded on built-in class hierarchies for the kinds of objects that can be added to a design. Examples are classes of walls, ceilings, beams, doors, and furniture. A design – in this respect – is a configuration of objects, and designing is a process of composition in which objects of classes are sequentially added to the design configuration. Class-based languages make the majority of objectoriented languages. In class-based languages, information is represented in objects by means of properties. Objects are instances of classes and contain methods for representing and manipulating object data. Classes—being type specifications for objects – group objects by definitions (Abadi and Cardelli 1996). An object—in object-orientation—is a named record of properties. Some of these represent intrinsic and extrinsic properties like material and position in space,

Semantic parameterized interpretation

93

respectively. Other properties denote functions (methods) for technical calculations, administrative procedures, and visualisation. In building design, the objects often represent potential artefacts. That is, man-made physical things which may come into presence in future. Most mechanical and architectural designing concerns artefacts. However, designing an artefact is not just a process of selecting a predefined object class or determining values for a set of predefined properties. That would obstruct the creative process of designing, as the it limits the space of possible artefacts to design. In (Ekholm 1995; Ekholm and Fridqvist 1998; Fridqvist 2000; van Leeuwen 1999; Eir and Ekholm 2002), foundations for conceptual design systems have been explored. Lately, such foundations together with the incremental process of designing, have been modelled using mathematical abstractions in order formally to capture the basic structures—the intrinsics—of the design process (Eir 2004a; Eir 2004b; Eir 2004c). Such intrinsic domain models are believed to serve as solid foundations for requirements and design of software systems (Bjørner 1997). It is argued that properties of objects are fundamental ontological entities in artefact descriptions, and that the design process can be seen as an incremental process which emphasizes the notion of multiple inheritance of properties. This understanding appears to be a suitable abstraction of design as a problem solving process. Furthermore, understanding design as an incremental process of set-inclusion of properties, appears to be a model capturing the essence of designing at early as well as at late stages. The approach is called property-orientation in contrast to object-orientation. An essential difference between property-orientation and the class-centered approach of object-orientation is that property-orientation maintains the property of subsumption (Eir2004c). In incremental designing, a solution to a technical problem is approached by incrementally ascribing properties to design objects. The process goes from the rough sketches of e.g. dimensions to more and more detailed descriptions. In this understanding, designing is incrementally ascribing a collection of properties to each object. This collection gives the object in question certain dispositions such that it offers certain ftmctionality in itself or in a complex. However, trying to introduce incremental designing in an object-orientation environment, yields a problem. Classes are types in the language in which the design program is written and changing a class by adding a property, requires code restructuring and recompilation. Thereby, object-oriented design systems lack of dynamics in two respects. The first is that the systems do not support incremental design; i.e. a process in which objects are being specialised incrementally by their kinds. In object-orientation, each object is “born” with a number of properties; those specified by its class. The second respect is that introducing new sorts of properties means restructuring the class hierarchy which again may require code restructuring and recompilation of the design program code. As a result, over time the class system may become complicated and even inconsistent (Eir 2004c). In this paper, we suggest a new software architecture which supports incremental design. The idea is to separate the conceptual models of artefacts from the perspectives that can be put on such models.

eWork and eBusisness in architecture, engineering and construction

94

In object-oriented CAD systems, certain methods represent different kinds of semantic information. One method could be a paint method which encodes a wall object and directs the graphical framework on how to display such objects. Another method could be one for calculating stress for wall objects of the class. A third method could be one which lists the bill of material for making a wall of this kind. The three methods are all relying on a conceptual model for wall objects. In the first case for describing shape, in the second for making engineering calculations, and in the third for making quantitative summations. The core information is the conceptual data, and each method puts on its own perspective by interpreting these conceptual data. The software architecture which is presented in this paper, aims at making this distinction explicit. It is founded on the idea that conceptual models are interpreted in various ways; each defining a specific perspective on the object in question. The principle thus moves class specifications to a dynamic level, thereby facilitating that properties can be introduced freely when these are needed in order to express the current design in mind. However, in order to succeed, the meanings of the terms that are taken to denote these properties, need to be specified. This is done in a semantic specification which becomes a parameter to the interpretation mechanism. The architecture is specified formally using the RAISE Specification Language (RAISE Language Group 1992). 2 ONTOLOGICAL PRIMER Our approach commits to a certain ontological picture of objects and properties. The aim is to separate entities which are intimately connected with design objects, from the ones which are not. The material of an object is intimately connected to an object as the existence of the property of being made of a certain material does not depend on the existence of other objects. Contrary, the load bearing ability of a beam is something which is only potential. It comes into play, only if other objects are present. This perspective draws on Shoemaker’s ontology which is an epistemological quest for justifying how we can know that an object has certain properties and what it means that it has these properties (Shoemaker 1997). In short our application of the ontological picture is this. The meaning of an object is its intrinsic (and if necessary, extrinsic) properties, and the meaning of having these properties (and thus the causal meaning of the object) is the collection of so-called causal dispositions. We can think of these dispositions as the fiinctionality offered by the object. From a collection of intrinsic properties, we derive that the object in question has certain dispositions. If a beam has certain dimensions and is made of a certain material, the beam possesses a specific strength and flexibility. However, these are only potential until the object is placed in a causal environment where laws apply. The notion of finctionality is this combination of intrinsic properties which are positioned in the causal environment through extrinsic properties like position in space. The specification of intrinsic properties states the ontological knowledge intimately connected to the object. Its functionality, behaviour, and possible application is an interpretation of these properties. Such an interpretation may define how the object looks like from various angles, or it may be the physical laws’ interpretation of the properties.

Semantic parameterized interpretation

95

Often, what is grasped when reading a design or requirements specification, is a collection of “images” constituting the meaning of what is read. Making various different interpretations of the same conceptual model corresponds to giving a collection of such “images”. This collection can be seen as our computerized way of representing the meaning of an artefact as an alternative to having it as a causally measurable thing. 3 MODELSANDVIEWS Artefacts like buildings can often be represented as conceptual models which list the properties of the artefact in mind. Consider the I-profile on Figure 1, which shall serve as our intuition in the following: The properties of the I-profile can be represented by the following conceptual model: [width → 400, height → 600, length → 8400, thA → 90, thB → 140, material → steel, sort → IPE] Assuming a certain way of understanding the names in the model, we can make the drawing on Figure 1. A conceptual model is meant for interpretation and many different perspectives can be put on this model. Such perspectives include representation of visualisation, calculations for stress analysis, etc. We shall now apply a language-oriented understanding of software systems. In this understanding design models are written in a formal language. This language needs to be extensible as we require that new properties can be introduced when these are necessary for expressing the current design idea. Properties are simply names (attributes) mapping to value names. Thus [material → steel] and [length → 3400] would correspond to attribute-value pairs for properties of a certain beam object; or of a beam class in general. However, even though such names may make sense in our normal understanding of artefacts, they do not in computing systems until we formally specify the meaning of them (Eir 2004c). In class-based systems, the meanings of collections of properties are “embedded” within certain class methods. E.g. apaintmQthod specifies how intrinsic properties like those of dimension, material and form, are to be expressed visually. The method defines a sort of interpretation of the data for doing so. However, adding the desired dynamics concerning properties, calls for separating such semantic information from the design program.

Figure 1. Steel profile.

eWork and eBusisness in architecture, engineering and construction

96

We can get a representation for visualising the I-profile by using the conceptual model as a substitution of free terms in an AutoLISP expression like: (command (list (list (command (list (list (command (list (command thA))) (list (list (command (list (list (command (list (command (list (list (command (list (list (command (list (list (command (list (command thA))) (list (list (command (list (list

′′line″ (/ width 2) (/ height 2)) (/ width 2) (/ height 2))) “line” (/ width 2) (/ height 2)) (/ width 2) (+(/ height 2) thA))) “line’ (/ width 2) (+(/ height 2) thA)) (list “line” (-(/ width 2) thB) (+(/ height 2) (-(/ width 2) thB) (+(/ height 2) thA)) (-(/ width 2) thB) (-(/ height 2)thA))) “line” (-(/ width 2) thB) (-(/ height 2)thA)) (/ width 2) (-(/ height 2) thA))) (list “line” (/ width 2) (-(/ height 2) thA)) (/ width 2) (/ height 2))) “line” (/ width 2) (/ height 2)) (/ width 2) (/ height 2))) “line” (/ width 2) (/ height 2)) (/ width 2) (-(/ height 2) thA))) “line” (/ width 2) (-(/ height 2) thA)) (+(/ width 2) thB) (-(/ height 2) thA))) “line” (+(/ width 2) thB) (-(/ height 2) thA)) (list “line” (+(/ width 2) thB) (+(/ height 2) (+(/ width 2) thB) (+(/ height 2) thA)) (/ width 2) (+(/ height 2) thA))) “line” (/ width 2) (+(/ height 2) thA)) (/ width 2) (/ height 2)))

Applying the substitution and evaluating algebraic expressions gives what we shall call a view on the model. The language in which it is written, we call a target language (t:£j). Entering the view in AutoCAD makes this tool display a visualisation of it, as shown on Figure 2. Using the substitution, we can also get a MATLAB expression of the shear stress distribution as a function of the thickness of the flanges: step=height/100; S-[]; x1—-height/2 : step : -height/2+thA; 51=thB/2*((height/2)~2-xl.~2); xm=-height/2+thA : step : height/2-thA;

Semantic parameterized interpretation

97

Sm=thB/2*((height/2+thA)~2-xm.~2)+ (width*thA/2)*(height+thA); x2=height/2-thA : step : height/2; 52=thB/2*((height/2r2-x2.~2); X=[xl xm x2]; S=[Sl Sm S2]; T=0:10 : thA; S'*T

Figure 2. Visualisation of I-Profile.

eWork and eBusisness in architecture, engineering and construction

98

Figure 3. Visualisation of stress in MATLAB. Applying the procedure mesh on the result in MATLAB, makes this tool display a stress visualisation as shown on Figure 3. The expressions having free terms to be bound, we call templates. A specification which determines the conditions for applying a certain template, is called a semantics. Thereby, a semantics defines the meanings of sets of properties in terms of target language expressions. In general, different semantic specifications may apply to the same model, and different models may use the same semantics. This principle is depicted on Figure 4, where mi denote conceptual models, Sj denote semantic specifications, and vij denote the resulting views. The process of producing a target expression from a model using a semantics, we consider a process of abstract interpretation (or just interpretation). In fact, an artefact model can be interpreted in as many ways as there are kinds of information to be derived from it.

Semantic parameterized interpretation

99

Figure 4. Models and views.

4 PARAMETERIZED INTERPRETATION The class of design systems we outline in this paper relies on a principle we call semantic parameterized interpretation. The design systems belonging to this class follow a common structure of components and connectors between components—they have the same software architecture (Bjørner 2003). This architecture is centered around an interpretation mechanism which utilizes a semantics in order to encode the meaning of objects from a design model, as target language expressions. The principle is based on the assumption that design models are expressed in a formal language. The meaning of a model—i.e. a perspective of what it may express—arises as a function of the meanings of the objects in the model. The meaning of an object is the set of properties ascribed to the object. The formal design model is expressed in terms which need interpretation. In order to do so, the meaning of the terms are specified in a semantic specif ication which binds sets of free terms to target expressions. Interpretation is now made in two stages. The first stage gives a target expression for each object in the model. However, such a target

eWork and eBusisness in architecture, engineering and construction

100

expression may be unsaturated in the sense that it may contain free terms and unevaluated expressions. The second stage aims at: (i) substituting such free terms with property values to which the terms—as attributes—are bound, (ii) evaluating expressions, and (iii) combining the resulting views into one. The second stage involves term rewriting and evaluation of expression. It requires what we shall call a calculus semantics CS which basically is a canonical set of rewriting rules. 5 ARTEFACT MODELS A conceptual model which represents an artefact in a design process, we call an artefact model. An artefact model (θ:Θ) is a mapping from object identifiers (x:X) to mappings from property designators (attributes) (a:A) to sets of values (vs:VS). The mapping from attributes to value sets is called a property pattern (σ:∑). Formally, we write:

An example is:

The empty set of properties corresponds to absurdum; i.e. the impossible or conflicting value of a property. It may appear as a result of combining two conflicting design solutions. 6 SEMANTICS A semantics defines the meanings of sets of properties. A semantics specification states expressions in target languages for a collection of property patterns. These are the patterns which are used to determine which target expressions represent the meaning of which kinds of objects. A semantics—in this respect—is represented by an environment (e:ENV) which maps property patterns (a:2) to unsaturated target expressions

Semantic parameterized interpretation

101

6.1 Target saturation The target expressions stated in a semantic environment are unsaturated in the sense that they may contain placeholders; i.e. free terms, and unevaluated arithmetic expressions. These free terms need to be bound to the values of properties; a process we shall call target saturation. The process is performed using a so-called calculus semantics (C5:CS). A calculus semantics is a function type which builds a term-rewriter and evaluator from a rule specification

The

resulting

fiinction

takes

an

unsaturated

target

and makes it saturated by using an artefact model for term expression substitution. Evaluation is performed according to the rule specification. The signature of the calculus semantics is:

As an example of a rule specification, consider the saturation of pre-fix addition of two properties with attributes a1 and a2 of an object (x:X):

We use the syntactical braces to emphasize that the expression on the left-hand side is considered syntax, whereas the expression on the right-hand side is semantics. We now have presented the necessary main components for semantic parameterized interpretation. The following sections aim at defining a number of necessary preconditions for performing interpretation of artefact models. 6.2 Completeness We specify a criterion for the applicability of a semantics in interpretation of an artefact model. We say that the semantics is complete concerning that model. A semantics represented by (e:ENV) is complete concerning a model represented by (θ:Θ) if and only if for all objects (x:X) of the model, the semantics contains a property pattern (σ:∑) which subsumes the property pattern of x. Formally, we write:

A property pattern (σ1:∑) subsumes another property pattern (σ2:∑) if and only if σ2 contains at least the attributes of σ1 and the value sets of σ2 are subsets of the value sets of σ1 for such common attributes. We say that σ1 subsumes σ2; written σ1<: σ2. E.g. the property pattern σ2= {200,220,240}] subsumes the pattern σ2=[width 100, height

eWork and eBusisness in architecture, engineering and construction

102

220]. Thus, σ2 is more specialized than σ1. The subsumption operation <: is defined on pairs of property patterns and pairs of properties, respectively:

6.3 Well-constrainedness Artefact models (θ:Θ) are meant for representing designs during a process of incremental specialisation. In such a process, it is convenient to specify several allowed values for properties. E.g. we may state that a window should be either 80 cm and 120 cm wide. However, when interpreting models, it is convenient that all attributes of object are only ascribed singleton value sets. For simplicity, we consider this rather strict criterion to be necessary in order for interpretations to be defined. We define the notion of well–constrained design models, as introduced in (Galle 1989), by the following predicate:

6.4 Non-ambiguity The notion of subsumption defines a partial order of property patterns. In such an ordering, ambiguity may occur if two distinct property patterns have common properties. In such cases, it may not be possible to determine which entry in the semantics to use. Therefore, it is required that such problems of ambiguity are resolved by introducing lattice meet as the combination of both entries. The most specialized property pattern— being the one we strive at finding—is represented by lattice meet. We define the following predicate for stating that a semantic environment is non-ambiguous:

Semantic parameterized interpretation

103

Lattice meet on pairs of property patterns is defined as:

Thus, the ordering of property patterns for a semantics must (at least) span a semilattice. 7 INTERPRETATION OF ARTEFACT MODELS We have now presented the necessary mechanisms for performing semantic parameterized interpretation of artefact models. The result is a view expressed in a target language This view is the result of interpreting each object in a model according to the semantics. This is done by selecting a property pattern in the domain of the semantic environment. This pattern has to comply with the properties ascribed the object. The result is an unsaturated target expression for that object. The target expression is made saturated by means of the calculus semantics. The target expressions, representing the meaning of objects in the artefact model, are finally combined. Figure 5 depicts the principle of semantic parameterized interpretation.

eWork and eBusisness in architecture, engineering and construction

104

The views of the objects are combined in a compositional way by folding using a binary operation on view pairs:

The function select picks the most specialized property pattern of those that comply with the pattern of the current object:

Figure 5. Semantic parameterized interpretation.

Semantic parameterized interpretation

105

8 POSSIBILITIES AND LIMITATIONS Besides offering the two kinds of dynamics concerning properties, the principle of semantic parameterized interpretation makes system integration and data exchange more flexible. It does so by cutting down to a minimum of ontological entities: properties and objects denoting sets of properties. These sorts of entities are common in all sorts of interpretations in civil engineering applications. Each application makes its own interpretations of the conceptual data model. Thereby we gain flexibility as application specific information is gained as the results of interpreting conceptual models within each application. E.g., a design system may focus on interpretations for visualisation whereas a planning tools may focus on economy and work procedures. However, the architecture which has been specified in this paper is highly abstract. It builds apon a compositional principle which says that the meaning of a whole is a function of the meaning of its constituents. There are, however, situations in which we wish to interpret a conceptual model according to a scheme which does not fit this principle. E.g., the principle excludes views which require that the meanings of objects are calculated from the meanings of other objects (in a non-cyclic way). Furthermore, the principle excludes views which require optimisation in order to be produced. However, in many cases, it is possible to write expressions in some fimctional languages such that the views can still be defined in a compositional way. In the paper, we have not made any distinction between intrinsic properties and extrinsic properties. In (Eir 2004c), we have argued that ontologically it is a desirable to do so, but technologically it may be inconvenient. As an example, introducing binar relations between objects (instead of having these as unary extrinsic position properties) may often require that free parameters need to be resolved through an optimisation process during interpretation. Introducing mechanisms for such resolvings makes the software architecture complicated as it involves the introduction of free parameters for unbound properties, and combinatorial algorithms for their resolving. In general, such issues are not important when considering the abstraction level at which we have presented the software architecture. However, they may be of interest when exploring the limits of the architecture as well as in further prototype development. 9 CONCLUSION In this paper, we have specified a new software architecture for conceptual design systems. The idea for the architecture has arised from the observation that today’s design systems lack of dynamics with respect to incremental specialisation of design objects and with respect to dynamic evolution of class systems for such objects. The architecture presented aims at introducing these dynamics by means of what is called semantic parameterised interpretation. In systems based on this principle, design models (artefact models) are written in a formal language. These design models refer to names of properties and values of these. The meanings of these names are not statically

eWork and eBusisness in architecture, engineering and construction

106

defined as in object-oriented class systems. The meanings of the names are given by a semantics which becomes a parameter to an interpreter mechanism. Artefact models are now interpreted according to a semantics and a calculus for evaluating expressions. The result is a view of the model which is a written specification in some target language It is essential to our principle that the same artefact model can be subject to many different interpretations—a principle which is highly important in today’s distributed and many-sorted realm of construction. Thus, we have shown how views for graphical presentation in AutoCAD and stress calculations in MATLAB, can be defined as interpretations of the conceptual design data. The interpretation of models is based on the properties of the objects, such that objects with the same properties have the same meaning, if using the same semantics. However, this induces problems if objects are described by the same set of properties even though they are intended to be conceptually distinct. It is then convenient to introduce special properties which aim at making such distinctions; e.g., a property with attribute sort. The property does, however, not denote class name, as it is optional and can be eliminated if the current distinction is not of interest. A design tool with the presented architecture is generic in the sense that the semantics—as a parameter—determines the sorts of entities that can be designed. Thus, a semantics specialises the architecture into a certain application. It may be argued that the problem we have tried to solve is much easier solved by means of database schemes. In such schemes, objects can be introduced as rows and properties of objects can be introduced as columns. There are, however, two main reasons why a database approach is not satisfactory. First, dynamically changing the attributes of a database schema—known as schema evolution—is hard when it comes to maintaining such schemas consistent. Second, the result of database operations and queries are either database schemas, tuples, or the field values of relations. It is essential to our approach that we are able to define the meaning of artefact models as expressions in many different incomparable target languages. We believe that the introduction of semantic parameterized interpretation can serve as inspiration for future research in this area, and that we have emphasized important issues and solutions relevant in the interdisciplinary field of design and computing. REFERENCES Abadi, M. and Cardelli, L. (1996). A Theory of Objects. Springer. Bjorner, D. (1997, October). Domains as a prerequisite for requirements and software: Domain perspectives and facets, requirements aspects and software views. In Proceedings US DoD/ONR Workshop, Bernried. Bj0rner, D. (2003). “What is a Method?” An Essay on Some Aspects of Software Engineering. Programming methodology. Monographs in Computer Science, 175–203. Eir, A. (2004a). Construction Informatics—issues in engineering, computer science and ontology. Ph.D. thesis, Chapter 5. Informatics and Mathematical Modelling, Technical University of Denmark, pp. 105–142. Eir, A. (2004b). Construction Informatics—issues in engineering, computer science and ontology. Ph.D. thesis, Chapter 6. An algebraic specification of incremental, conceptual building design, pp. 143–178. Informatics and Mathematical Modelling, Technical University of Denmark.

Semantic parameterized interpretation

107

Eir, A. (2004c). Construction Informatics—issues in engineering, computer science and ontology. Ph.D. thesis, Chapter 7. Semantic parameterized interpretation as a foundation for conceptual design systems, pp. 179–224. Informatics and Mathematical Modelling, Technical University of Denmark. Eir, A. and Ekholm, A. (2002). From rough to final designs by incremental set-inclusion of properties. In eWork and eBusiness in Architecture, Engineering, Construction, proceedings ofthe ECPPM2002, pp. 293–300. Swets & Zeitlinger Publishers. Ekholm, A. (1995). A conceptual framework for classification of construction works. IT con 1. Ekholm, A. and Fridqvist, S. (1998, June). A dynamic information system for design applied to the construction context. In B.-C. Bjork and A. Jagbeck (Eds.), Proceedings of the CIB W78 workshop The life-cycle of Construction IT, pp. 219–232. Fridqvist, S. (2000). Property-OrientedInformation Systems for Design. Ph. D. thesis, Division of Architectural and Building Design Methods, Lund University. Galle, R (1989). Computer methods in architectural problem solving: Critique and proposals. In CAAD: Education—Research and Practice (eCAADe), pp. 6.4.1–6.4.21. RAISE Language Group, T. (1992). The RAISE Specification Language. Prentice Hall, CRIA/S. Shoemaker, S. (1997). Causality and properties. In D.H.Mellor and A.Oliver (Eds.), Properties, Oxford Readings in Philosophy, pp. 228–254. Oxford University Press. van Leeuwen, J. (1999). Modelling Architectuml Design Information by Features, andapproach to dynamicproduct modelling for application in architectural design. Ph. D. thesis, Eindhoven University of Technology, The Netherlands.

eWork and eBusiness in Architecture, Engineering and Construction—Dikba§ & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Harmonization of ISO 12006–2 and IFC– a necessary step towards interoperability A.Ekholm Lund Institute of Technology, Lund, Sweden ABSTRACT: There are two major candidates for Core Ontologies for the construction and facilities management sector, the ISO 12006–2 Framework for classification of information, and the Industry Foundation Classes, IFC. ISO 12006–2 has been developed to harmonize different national and regional classification systems. The IFC are intended to enable effective information sharing within the AEC/FM industry. The standards have similar objectives but show fundamental differences in semantics and structure. This work compares the standards and points at similarities and differences, firstly in order to understand their structure, and secondly to initiate a discussion about the need and the possibility to co-ordinate them. The starting point of IFC was to reject classification, and therefore a harmonization with ISO 12006–2 would require a major shift of approach. Development of a common meta model, a generic domain model, and a coordinated domain framework are considered necessary tasks.

1 ONTOLOGIES FOR CONSTRUCTION AND FACILITIES MANAGEMENT The demand for standardised concepts and terminology rapidly increases in the construction and facilities management sector. Internationalisation of the industry and an increasing use of information systems are decisive factors in this development. A generally agreed ontology is a prerequisite for effective information exchange and interoperability in any field of knowledge (Lima 2004). The development of the semantic web with agent based information retrieval is a current example, where interoperability is enabled through ontology development and standardisation (Berners-Lee et al. 2001). An ontology consists of concepts that describe objects of interest in a domain. The ontology for the construction and facilities management sector comprises concepts for describing construction entities, their design, production, use and management, as well as man using and experiencing the built environment. Internationally agreed ontologies in the sector are scarce, the post-war world wide spread of the SfB building classification system was an exception. Classification systems are cornerstones in ontology development, they concern both concepts and terminology and have a decisive influence in establishing a common language for actors in a sector. Lately the interest in ontology for the construction and facilities management sector has grown, at first connected with the interest in product

Harmonization of ISO 12006-2

109

modelling and now with the emergence of xml-based information exchange (Tolman 2000). The construction and facilities management sector is traditionally national and regional in character. Today, there are two major candidates for core ontologies common to the sector, ISO 12006–2:2001, Building construction-Organization of information about construction works-Part 2: Framework for classification of information (ISO 2002), and Industry Foundation Classes, IFC, developed by the International Alliance for Interoperability, IAI (IAI 2000). ISO12006–2 defines a framework of generic classes of interest in construction and facilities management. It is intended to be used as a starting point for development of detailed classification tables. Tables that adhere to the principles laid out in the standard are assumed to be similar and possible to translate between. ISO12006–2, with its roots in the SfB-system, has recently been applied in the development of building classification systems like the British UNICLASS (RIBA 1997), The Swedish BSAB 96 (The Swedish Building Centre 1999) and the North American OCCS (OCCS 2003). The scope of ISO12006–2 is the complete lifecycle of construction works but it is not specifically considering the needs of ICT-based interoperability. IFC addresses interoperability requirements and has a similar scope concerning both construction and facilities management. IFC consists of a framework of classes and models and is intended to be used as a resource for development of schemas in model oriented information systems. Although its aim is not to develop a generic building classification, its framework of classes is similar to those of ISO 12006–2. An ontology for the construction and facilities management sector must be common to the worlds of classification and product modelling. Already in the introduction of product modelling research the idea of harmonization with building classification was suggested by Bjork in the “Unified Approach Model” (Bjork 1992). This model was later integrated into the IRMA model (Luiten et al. 1993). Both are compatible with the basic structure of ISO 12006–2. Both ISO 12006–2 and IFC have as purpose to establish a foundation for development of effective information systems for the construction and facilities management sector. However, there are marked differences in semantics and structure of the systems. The aim of this research is to compare the structure of the standards, to point at similarities and differences, in order firstly to understand why these standards are so different, and secondly to initiate a discussion about the need and the possibility to co-ordinate them. The following sections analyse and compare the structure of ISO 12006–2 and IFC, discusses information requirements in critical processes, compares with other standards, and reflects on a strategy for harmonizing the FST and IFC. 2 THE STRUCTURE OF ISO 12006–2 The ISO 12006–2 standard has been developed as a step in harmonizing different national and regional building classification systems. It is intended to be used as a framework for developing building classification systems by organisations on a national or regional basis. An underlying assumption is that the ISO-standard in the long run will enable the development of common tables in an international level.

eWork and eBusisness in architecture, engineering and construction

110

ISO 12006–2 “defines a framework and a set of recommended table titles supported by definitions, but not the detailed content of these tables” (ISO 2002:6). It is based on many years of practical experience, and is also shown to be compatible with scientific ontology and systems theory (Ekholm 1996). ISO 12006–2 identifies the main classes that are of interest to the construction sector’s building classification for purposes of CAD, specification, product information and cost information systems (ISO 2002:4). The scope of the standard is the complete life cycle of construction works within building and civil engineering. It lists recommended tables according to particular views or principles of specialisation and gives

Figure 1. The high level process model in ISO 12006–2. examples of entries that may occur in these tables (ibid:6). The ISO standard has not been expressed in a formal data definition language. The standard illustrates objects and relations in an informal schema which for reasons of space is not shown here. The relations between objects are depicted with arrows representing subclass relations and other associations between classes and properties. The schema together with the definitions in the standard are sufficient as a background for representing the standard in a more formal way in EXPRESS-G diagrams, which make a comparison with IFC easier. In the following text the ISO Framework Standard, will be named FST for short, and the classes of the standard will be given short names to fit within the schema boxes. 2.1 The FST Construction Object The most generic entity in the FST is the Construction Object, defined as an object of interest to the construction industry. The FST identifies four main classes of Construction Object: Construction Resource, Construction Process, Construction Result, and Property/Characteristic. These are related in a generic process model stating that Construction Resources are used in Construction Processes that will result in Construction Results, and all these objects have Properties/Characteristics. Every class in the standard is a subclass of one these four. Relations are not treated explicitly in the standard but may be treated as mutual properties of the related objects. The EXPRESS-G schema in Figure 1 illustrates these most generic classes.

Harmonization of ISO 12006-2

111

The FST does not suggest any classification for properties but gives examples from the CIB Master List, e.g. composition, surface and sensory, thermal etc. Generally, building classification systems do not handle geometrical properties, since they are supposed to be used together with drawings or models that contain this information. 2.2 FST Construction Process Among the processes defined by FST, “Construction entity life-cycle stage” is an overall process related to

Figure 2. Processes in ISO 12006–2.

Figure 3. Resources in ISO 12006–2. the construction entity, e.g. design or production. See Figure 2. “Project stage” is defined as a “period of time in the duration of a construction project identified by the overall character of the construction processes within it”. According to this definition, “Project stage” is a part-process of “Construction entity life-cycle stage”, e.g. building programming or detailed design. “Management Process” is a planning or administrative process. A “Work Process” leads to a “Work Result” which is a result classified according to process or kind of work.

eWork and eBusisness in architecture, engineering and construction

112

2.3 FST Construction Resource Resources in the FST are shown in Figure 3. A “Construction Product” is a resource intended for permanent incorporation in a construction entity. Members of “Construction Aid” are resources like tools and machinery, not intended for incorporation in a permanent manner in a construction entity. The properties of a “Construction Product” are basic to the properties of the built parts of the construction entity. 2.4 FST Construction Result The FST identifies four main classes of result: “Construction Complex”, e.g. airport and motorway, which consist of one or more “Construction Entity”, e.g. building and bridge, and “Construction Entity Part”, e.g. wall and road surface. A “Space”, e.g. a room or roadway, is “contained within or otherwise associated with a building or other construction entity” (ibid:9). See Figure 4. The Result classes identified in

Figure 4. Construction Result according to ISO 12006–2. the FST seem limited in the sense that they describe material results. However a possible interpretation is that also information like design results, e.g. ideas and abstract models, representing concrete results are possible members of these classes. The generic result classes “Construction Complex”, “Construction Entity” and “Construction Entity Part” are related by a part-of relationship in a compositional hierarchy. The result classes are “abstract” and only intended to be instantiated after a first division into subclasses based on different views on the physical reality they

Harmonization of ISO 12006-2

113

represent. According to the FST, a “Construction Complex” is classified by function-oruser activity. A “Construction Entity” is classified either by form or by function-and-user activity. “Construction Entity Part” is classified by function as “Element”, by type of work as “Work Result” and as “Designed Element” by subdividing “Element” by “Work Result. “Space” can be classified by enclosure, e.g. outdoors or indoors, by user functionoractivity or by a combination of these. “Space” in the FST has no relation with “Construction Entity Part”. A relation like “enclose” or “composed of” would seem relevant according to (Ekholm and Fridqvist 2000). The subclasses based on separate views are included in Figure 4. From the example of Designed Element it is easy to imagine the need for other combined classes e.g. “Designed Construction Entity” and “Designed Space”. The Swedish BSAB 96 has a classification table for construction entities that could best be described as “Designed Construction Entity”. It is a combination of “Construction Entity by Form”, e.g. tunnels, bridges and buildings, and “Construction Entity by Function” (The Swedish Building Centre 1999). The difference in view is motivated by the purpose of the classification, if it is of importance to identify Construction Entities by the main construction method, e.g. girder bridge, arch bridge, or truss bridge, or by function-oruser activity as railroad bridge, motor vehicle bridge or pedestrian bridge. A similar subdivision is possible for “Space”, e.g. indoors or outdoors specify form, e.g. kind of enclosure, and living room or kitchen specify fimction-or-user activity. 3 IFC AND THEIR RELATION TO ISO 12006–2 3.1 The objective of IFC The IFC constitute a framework for sharing information between different disciplines within the AEC/FM industry throughout the project lifecycle (IAI 2000:2). The main purpose of the IFC is to enable effective information exchange between information systems, so called interoperability. This concerns both semantic definitions and object exchange formats. The semantic definitions of the IFC concern, just as ISO 12006–2, objects of interest in construction and facilities management. However, IFC does not adhere to the ISOstandard and has different definitions and general structure. The documentation of IFC does not present a theoretical background for its structure or choice of model classes. IFC has gone through several practical tests that confirm its applicability and it is integrated in an increasing amount of applications. However, with the exception of an earlier study by the present author (Ekholm 1999), IFC has never been subject of a detailed critical analysis concerning its relation to building classification. 3.2 Conceptual layers The organization principle for the IFC framework provides for a modular structure of models (ibid:5). The models are structured into conceptual layers of different scope. There are four conceptual layers where sets of model schemata are defined (ibid:5):

eWork and eBusisness in architecture, engineering and construction

114

1. Resource classes. 2. Kernel and Core Extension classes. 3. The Interoperability classes. 4. The Domain classes. The Resource layer contains classes that are applicable to most of the classes in other layers, e.g. geometry, date and time, material and cost. Resources could be understood as representing generic properties of domain objects. The Core layer consists of the Kernel and the Core Extensions. The Kernel provides all the basic concepts required for IFC models. In an early version of the standard the Kernel is explained as “a kind of Meta Model that provides the platform for all model extensions” (IAI 1997:6). In a later version the Kernel is explained as a “template model that defines the

Figure5. The IFC “template model”.

Figure 6. IfcObject. form in which all other schema within the model are developed… The Kernel is the foundation of the Core Model” (IAI 2000:8). The Kernel is independent of the AEC/FM domain.

Harmonization of ISO 12006-2

115

3.3 The IFC Kernel IFC uses EXPRESS as data definition language. The basic data units in EXPRESS are entities, relationships and attributes (Schenck and Wilson 1992:26). The IFC apply these units as a starting point to define the Kernel objects consisting of IfcRoot with the subclasses IfcObject, IfcRelationship, and IfcPropertyDefinition (IAI 2000:12). See Figure 5. IfcRoot is the most generic entity, it has name, ID, description and history. IfcObject represents concrete and conceptual objects in the domain. Among examples are wall, space, grid, work task, cost item, labour resource, actor, and person. IfcRelationship represents relations between members of IfcObject, and relations to support modelling for database implementation. IfcPropertyDefinition represents different attributes of domain objects. The fact that relationships are treated separate from properties seem odd since relations are mutual properties, e.g. “position” and “before” are properties based on relations between two or more things. The immediate subclasses of the “template model” constitute a second level in the Kernel. Subclasses of IfcObject are shown in Figure 6. In contrast with the FST, the IFC classes are not related in an explicit definition or model and one may wonder whether the selection is complete or if the classes are mutually exclusive, as they would be in a classification system. To compare, for example the IfcResource is not equivalent to the FST Resource. An IfcResource is defined as “information needed to represent the costs, schedule, and other impacts from the use of a thing in a process … It is not intended to use IfcResource to model the general properties of the things themselves”. This is radically different from the standpoint of the FST where a Resource like FST Construction Product is defined as “a commodity that may be incorporated into a construction entity in a permanent manner”. The IfcResource is an attribute, representing properties of resources, while the FST Resource is a class concept referring to concrete resources. The FST Resource class may be used independently of other classes while the IfcResource requires an instance of IfcProduct to be applied. An IfcProduct is defined as a physical item incorporated into an AEC/FM project either directly as supplied or through construction/assembly of other products. IFC does not distinguish between the FST classes FST Construction Product and FST Element. Within the second level of the Kernel, the IfcRelationship class is specialised into five categories, IfcRelAssigns, IfcRelConnects, IfcRelDecomposes, IfcRelAssociates, and IfcRelDefines. These relate IfcObject to different other IfcObject, e.g. IfcRelAssigns may be used for an arbitrary relation between objects, IfcRelConnects may represent a physical coupling, IfcRelDecomposes represents the part-of relation and IfcRelDefines is used for relating Property Sets or Type objects with an object instance. Each relationship is further specialised according to the specific object that it relates, e.g. IfcRelAssignsToResource. The same reflections as for the IfcObject subclasses are relevant to make for the IfcRelationship classes: are the different kinds of relationship theoretically well-founded, is the selection exhaustive?

eWork and eBusisness in architecture, engineering and construction

116

3.4 The Core Extensions The classes described above constitute the IFC Kernel. The next level is the Core Extensions layer, which consists of specialisations of the Kernel classes IfcControl, IfcProcess and IfcProduct. The subclasses of IfcProduct are IfcElement, IfcSpatialStructureElement, IfcAnnotation, IfcGrid and IfcPort. Figure 7 shows the subclasses of IfcElement and IfcSpatialStructureElement. Subclasses of IfcElement are defined as components of an AEC product. The names indicate that they are identified by function and thus similar to the different FST Elements. However, this is not the intention as shown below in section 5.1. IfcSpatialStructureElement classes are only spatially defined. In the technical documentation of IFC 2×2,

Figure 7. IfcElement and IfcSpatialStructureElement a spatial enclosure hierarchy shows IfcSite, IfcBuilding, IfcBuilding seen as section of a building, and IfcBuildingStorey related through IfcRelAggregates, a subclass of IfcRelDecomposes (IAI 2003:102). In FST, Construction Complexes, Construction Entities and Construction Entity Parts are related in a compositional hierarchy, as illustrated in Figure 4. A spatial hierarchy of enclosure similar to IFC:s could be developed in parallel to the compositional hierarchy. The FST does not mention the concept of construction site explicitly, but in principle it

Harmonization of ISO 12006-2

117

could be seen as a construction complex consisting of related construction entities like roads, buildings, pavements etc. The other kinds of space would be derived from a spatial view on construction entities and construction entity parts. The FST does not specify how relations between different kinds of spaces are handled. For example, the relation between a room and a building storey is not covered by the FST. IFC needs to support this kind of specification but could be improved by applying a more generic view of the concept of space and how it is related to buildings and parts of buildings. Examples of relevant analyses of the concept of space are presented in (Ekholm and Fridqvist 2000) together with a proposed definition of space relevant for both classification and product modelling. Here, the concept of space is included in a theoretical framework that also considers other aspect views on the building, e.g. functional systems and their parts. Although IfcGroup is not an IfcProduct, it has two subclasses in IFC Product Extension, IfcSystem and IfcZone. IfcGroup could be understood as a generic class describing an arbitrary aggregate of members of IfcObject. Functionally related parts of a collection may be represented together as IfcSystem. Similarly if the collection consists of adjacent spaces the collection may be represented as IfcZone. The seemingly ad hoc based position of these classes in the Core Extension may be explained as a consequence of the lack of theoretical foundation for the development of the IFC framework. The generic concept of system should be defined already in the most generic, ontological level, of the framework e.g. stating that any object may be a system composed of parts. 3.5 The Interoperability Layer The next lower level is called the Interoperability Layer. It contains classes common to different actors and disciplines in the construction and facilities management sectors. Here one may find, for example, IfcWall, IfcBeam, and IfcElectricalAppliance. The classes of the interoperability layer are intended to be generic in scope. One example is the class IfcWindow which is a “leaf node” in IFC, i.e. it is not subclassed in the standard. Further detailing is achieved through assigning Property Sets, e.g. that assign different numbers of glazing panes, opening types, framing arrangements etc. The classes in this level are similar to those in classification tables of national and regional classification systems. However, the classes are not intended to be equivalent to those in classification as will be shown in section 5.1. 4 VIEWS IN CONSTRUCTION AND FACILITIES MANAGEMENT 4.1 Views on Construction Entities The separation of classes from spatial, functional, and compositional views and the possibilities to combine these is characteristic to several processes in construction and facilities management. The difference in view is motivated by the purpose of using the information, for example, whether it is of importance to identify a construction entity by main construction method or by function-or-user activity.

eWork and eBusisness in architecture, engineering and construction

118

The example given above in relation to the FST described a bridge as a girder bridge, arch bridge, or truss bridge, and as a railroad bridge, motor vehicle bridge or pedestrian bridge, respectively. The fimctional-or-user activity view on the Construction Entity may be of specific interest in the brief stage or in the facilities management stage. Similarly, the compositional view may be of interest during systems design, detailed design, production and maintenance, where knowledge of composition and constituent materials are necessary. There is no equivalent in IFC to the FST classes Construction Entity by Form and Construction Entity by ftmction-or-user activity. The only IFC class in this level is the IfcBuilding, a subclass of IfcSpatialStructureElement, a semantically spatial concept. 4.2 Views in design The FST reflects the idea of design as a process where functional requirements are met with technical solutions and concrete work results. There is a need for separate classes for these views, since they concern different stages and actors in the construction process. The FST classes for construction entitiy parts are “Element”, “Designed Element” and “Work Result”. During design, building classification supports the successive determination of properties of the designed object. At first the designed object is identified through a spatial view, location and geometry are determined. Next, the object is functionally determined and can be classified as Element. When the technical solution of a part has been determined it may be classified as Designed Element and Work Result. In principle the sequence is the same in drawing based design and 3D-model based CAD, the designer starts by defining design objects, i.e. building parts, by geometry, and successively determines fimction and technical solution. However, the main 3D-modelling CAD-applications integrate the first two steps and require a designer to instantiate a design object from an Element class with predefined geometry parameters, e.g. a wall as a vertical plate. In this case the instantiated object is already determined by fimction according to the definition of the Element class. 4.3 Views in specification and cost calculation In order to develop a specification or cost calculation using the FST each Element is specified by Work Results including used resources, e.g. labour and material. Table 1 illustrates a specification using the Swedish classification system BSAB 96 from a prototype test of information transfer from product model

Table 1. The structure of a specification based on BSAB 96. E-code

Element(E)

WR-code

Work Result (WR)

Unit

27.G

Roof carcass

HSD.113

Beam framework

length (m)

HSD.2

Glue-laminated wood beam

length (m)

Harmonization of ISO 12006-2

119

GSN.17

Rooftruss

amount (no)

ZSE

Angular fittings

amount (no)

to cost calculation using IFC and BSAB 96 (Nilsson & Eriksson 2002). IFC cannot handle cost calculation in this way since it does not identify classes based on different views. Instead, cost calculation is enabled by associating instances of IfcProduct, e.g. IfcBuildingElement, with IfcConstructionResource and related IfcCostltem (IAI2003). It would seem more relevant to use predefined classes like FST Work Result to handle this. Applications for design, specification, and cost calculation might require that objects emerging from different views are concatenated during the processes. This requires support for multiple inheritance. An obstacle for IFC could be that it only allows single inheritance (IAI 2000:39). 4.4 Views in other standards The recognition of the relevance of distinguishing classes from different views is not unique to the FST, rather, it is common in other standards. For example, STEP AP 221 “EPISTLE”, used for Product Data Management separates between a “functional physical object” which represents a fimctional view on an object in the domain, while the “materialized physical object” includes both a functional and a compositional view (EPISTLE 2004). Another industry standard, IEC 61346 “Industrial systems, installations and equipment and industrial products”, developed for classification of “technical objects”, for similar reasons as the FST, distinguishes between objects identified from three different views, the functional: “fiinction”, the compositional: “product” and the spatial: “location” (IEC 2000). 5 CONCLUSION OF THE STUDY 5.1 Classification and product modelling As a starting point for the development of IFC, the relevance of building classification for product modelling was questioned since “it only allows a user to categorize elements according to primary functional role or as part of a system” (IAI 1997:2–15). The developers of IFC intended to “avoid this by defining model elements, functional roles, and systems separately so that an element can assume multiple roles and/or be a member of multiple systems”. The development of IFC has been guided by these principles. As a consequence the IFC Core Extension and Interoperability classes are not intended to be equivalent to classification classes, but should be seen as some kind of placeholders for information about the modelled instance. The properties of the instance are determined through associations with GeometryResources, PropertySets and other classes in IFC.

eWork and eBusisness in architecture, engineering and construction

120

Accordingly, in order for an IFC instance to be classified as an FST Element it would need to be assigned a Property Set equivalent to that of the Element definition. In prototype tests of IFC this has not been tried out, but instead the IFC class names have guided the interpretation of the IFC classes as functional elements. Where such IFC classes have been missing the IfcProxy class has been applied to represent among others Work Result classes (Tarandi 2003). The problem with the IFC approach is the idea that “model elements” may be identified independent of e.g. a spatial, functional, or compositional view. Philosophers and scientists generally agree that it is not possible to have knowledge about the world “as it is“but only “as we see it”. Popper says that “If we wish to study a thing, we are bound to select certain aspects of it” (Popper 2002:71). We see the world through our concepts, and these are by definition classes (Bunge 1979:169). In principle we cannot refer to anything without at the same time “see it as” something. Even to say “that thing” is to classify it as having existence. When we call something a “wall” we immediately include the thing into the fiinctionally defined class of enclosing/dividing things. It is impossible to focus on an object without at the same time assigning it to a class. Similarly an instance is by definition member of the class it is instantiated from. If IFC had applied its principles it would enable a model element to be instantiated in a generic level independent of functional, compositional, or spatial definition. But this is not supported, e.g. all classes from IfcRoot down to IfcBuildingElement are abstract and cannot be instantiated (IAI 2003:114). In practice IFC has not succeeded in establishing the intended separation between model elements and classification. The IFC classes have, to a large extent, similar names as those used in classification systems. An example is the IfcWall, which also in IFC is defined by its functional role as “enclosing”. Instances of this are not independent of functional role. This would not have been problematic if IFC had acknowledged the fact and adhered to FST or any other classification framework. In fact building classification supports precisely the process which IFC strives for. As explained above, classification classes must be seen as part of the information that is determined in the process alongside with the geometry information expressed by drawing objects. This fact is an important argument for revising the IFC class structure in adherence to the FST. 5.2 Integrating FST and IFC, is there a possible strategy? Recently, based on the experiences of the Workshop on eConstruction, the need for a strategy for development of a unified building construction model has been stressed (Wix 2004:32). The analysis presented here suggests that the harmonization of building classification represented by ISO 12006–2, and product modelling, represented by the IFC, should be an essential part of the work. What would be the reason for harmonising FST and IFC? Classification systems adherent to the FST are used in daily practise in several countries for both manual and computer based information structuring. IFC specifically addresses questions of interoperability and represents a considerable investment of time and money. If IFC and the FST were harmonized it would facilitate and speed up the integration of everyday practise with object based information management.

Harmonization of ISO 12006-2

121

Would it be possible to integrate these standards? The FST and IFC both lack an explicit theoretical foundation, and establishing a common ground would effectively support an integration process. Compared with FST, the IFC:s framework is more ad hoc which makes it harder to understand, apply and develop. A framework for information systems in the construction and facilities management sector should be both theoretically well founded and practically applicable. The former will increase versatility and life span of the standard. The FST and IFC support slightly different processes, but, as shown, there is a significant overlap between the frameworks. The FST is developed to support specification, cost calculation, CAD-layering, PDM-systems, brief development, etc. for the construction and facilities management processes. IFC has a similar scope, but the needs of CAD-systems and the definition of CAD objects were initially in focus. How could the harmonisation be accomplished? A starting point would be to abandon the IFC strategy of “defining model elements, functional roles, and systems separately” and acknowledge the need for a framework based on views and classification. Then, it would be necessary to define a “meta model” based on generic principles for modelling domain objects starting, not from the EXPRESS language, but ifrom very generic ontological theories, e.g. a general theory of systems and properties. This would include the definition of objects from different views. An attempt in this direction may be found in (Ekholm and Fridqvist 2000). A next consideration would be to build a generic domain model similar to that of FST or the IRMA that defines the main classes, including objectified relationships, needed to build the model schemas. The overall aim would be to develop a framework for object oriented information exchange for construction and facilities management that would be both scientifically well founded, and applicable and acceptable for the processes that are to be supported. REFERENCES Berners-Lee, T et al. 2001. The Semantic Web. Scientific American. May 2001. Accessed at http://www.sciam.com/ article.cfm?articleID—00048144–1OD2–1C70–84A9809 EC588EF21 &ref=sciam&chanlD—sa006. Bjork, B.-C. 1992. “A Unified Approach for Modelling Construction Information”. Building and Environment. Vol. 27,No2.pp 173–194. Bunge, M. 1983. Epistemology & Methodology I: Exploring the world. Vol. 5 of Treatise on Basic Philosophy. Dordrecht and Boston: Reidel. Ekholm, A. 1999. “Co-ordination of classifications for product modelling and established building classifications”. In: Durability ofBuilding Materials & Components 8, Vol. 4 Information Technology in Construction, Proceedings of the CIB W78 Workshop at the 8dbmc conference May 30-June 3, Vancouver, Canada (Eds.) Lacasse M.A. and Vanier D.J. NRC Research Press, Ottawa, Canada. Ekholm, A. 1996. “A conceptual framework for classification of construction works”. Electronic Journal of Information Technology in Construction (Itcon). Vol. 1 1996. http://itcon.org/. Ekholm, A., & Fridqvist, S. 2000. “A concept of space for building classification, product modelling and design”. Automation in Construction, (9)3. EPISTLE 2004. EPISTLE core Model 4.5. Accessed 2004–04–01, at http://www.epistle.ws/,http://www.infowebml. org/ECM4.5/ECM4.5.html and http://www.btinternet/. com/~Chris. Angus/epistle/standards/ap221 .html.

eWork and eBusisness in architecture, engineering and construction

122

IAI 2003. IFC 2x Edition 2. Model Implementation Guide. Version 1.6. (Ed.) Liebich, T. International Alliance for Interoperability, June 30, 2003. IAI 2000. IFC Technical Guide. (Eds.) Liebich, T. & Wix, J. International Alliance for Interoperability, October 27, 2000. IAI 1997. Industry Foundation Classes—Release 1.0 Specifications Volume 2. IFC Object Model For AEC Projects. International Alliance for Interoperability, January30, 1997. IEC 2000. IEC 61346–3: Industrial systems, installations and equipment and industrial products— Structuring principles and reference designations—Part 3: Application guidelines. 2000–05–05. International Electrotechnical Commission, IEC. ISO 2002. Svensk Standard SS-ISO 12006–2:2001, Building construction—Organization of information about construction works—Part 2: Framework for classification of information. Sprak: Svenska och Engelska. Geneva: Int. Organisation for Standardization. Lima, C. 2004. Final draft CWA4 proposal “European eConstruction Ontology “version 2004–03– 26. Workshop on eConstruction N083, Nederlands Normalisatie-Instituut. Luiten, G. et al. 1993. “An Information Reference Model for Architecture, Engineering, and Construction”. Proceedings of the First International Conference on the Management of Information Technology for Construction, Singapore, August 1993. Nilsson, K. & Eriksson, V 2002. Pilotprojekt NCCProdiiktion plus overlamnande. Koppling mellan produktmodell och kalkyl- och forvaltningssystem. Slutrapport 2002–12–17. IT Bygg & Fastighet 2002. OCCS 2003. Overall construction classsification system. Accessed 2004–04–01 at http://www.occsnet.org//. Popper, K. (2002). The Poverty of Historicism. First published 1957. London: Routledge. RIBA 1997. Uniclass. Construction Project Information Committee. London: RIBA Publications. Schenck, D. & Wilson, P. 1992. Information Modelling: The EXPRESS Way. Oxford: Oxford University Press. The Swedish Building Centre 1999. BSAB 96. The Swedish construction industry classification system. Stockholm: The Swedish Building Centre. Tarandi, V 2003. Implementering av produktmodeller baserade pa IFC och BSAB. Slutrapport 2002–12–18. IT Bygg & Fastighet 2002. Accessed 2004–06–07 at: http://www.itbof.com/2002//implementering_produktmodeller.doc. Tolman, F. et al. 2000. The bcXML Baseline. eConstruct IST-1999–10303, WPl, Tl 100, DlOl, Rev.4. Accessed 2004–06–07 at: http://www.bcxml.org/ 6Public/bcXML_CD/PublicDeliverables/dl01_v4.pdf. Wix, J. 2004. draft CWA3 “European eConstruction Metaschema” version 2004–03–01. Workshop on eConstruction N068, Nederlands Normalisatie-Instituut.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

A novel modelling approach for the exchange of CAD information in civil engineering Berthold Firmenich CAD in der Bauinformatik, Bauhaus-Universitdt Weimar, Germany ABSTRACT: Existing CAD systems are predominantly incompatible. Standardization attempts describe the structure of the data to be exchanged. The information exchange is realized by data transformation. Due to incompatible data schemes this process normally (1) results in the loss of data that (2) accumulates during each information exchange. In the traditional approach information is exchanged in an evaluated form. This paper presents a novel solution approach that describes the information to be exchanged in an unevaluated form: Instead of exchanging objects and attributes, the applied operations are exchanged. This approach is denoted as operative modelling. The generation and the description of the applied operations are presented. The advantages of the novel approach over the traditional approach are clarified by means of typical scenarios and examples from civil engineering.

1 MOTIVATION Existing CAD systems are predominantly incompatible. Standardization attempts describe the structure of the data to be exchanged. However, existing CAD systems are normally not based upon standardized data structures: The completion of their specific tasks very often requires the usage of optimized data structures. Thus, the information exchange is characterized by two data transformations: One transformation from the native format of the source system to the standard exchange format and one transformation from the standard exchange format to the native format of the destination system. Due to incompatible data schemes this process normally (1) results in the loss of data that (2) accumulates during each information exchange. 2 OBJECTIVE Available CAD systems store their models in an evaluated form as objects and attributes. In this paper the new research project opCAD is introduced: The objective of this project is the standardization of CAD in civil engineering by a language for unevaluated CAD models. Such an unevaluated model is not described by objects and attributes, but by the operations that have created the model. The unevaluated model is called an operative model.

eWork and eBusisness in architecture, engineering and construction

124

In available CAD systems the user stores the result of the construction process at certain points in time. In the new approach the sequence of operations executed in the construction is described by a language to be developed in the research project. This operative model is continuously and implicitly stored by the system. The recorded activity of the construction process can be played back later. The main objective of the research project is the systematic and complete description of a practical language for the operative modelling of CAD in civil engineering. 3 TRADITIONAL DATA EXCHANGE 3.1 State-of-the-art Existing standardization attempts focus upon the description of the results of the planning process. The international organizations OMG (Object Management Group) and ODMG (Object Database Management Group) define interfaces for the usage of objects in a distributed environment and in object oriented databases (Serain 1999, Eastman 1999). The SQL language has been standardized by the American National Standards Institute (ANSI). SQL is a language for relational data models. The description of objects and operations by the SQL language would be very cumbersome. The ODMG has provided with OQL (Object Query Language) a standardized language for the selection and manipulation of object models. OQL-instructions can be optionally embedded in programs or can be used by experienced users as an ad-hoc query language. OQL allows the selection of objects and their manipulation by calling methods. Attribute values can be modified. The application of OQL by a user would require a deep understanding of object oriented methods. In addition to that the formulation of operative models by the OQL language would be a tedious task. Another solution approach consists of the formulation of scripts for CAD. The Tc1/Tk (Tool Command Language/Tool Kit) language is commonly used as scripting language. Although the language allows the formulation of CAD macros no standardization took place until now. However, Tc1/Tk could be an environment for the implementation of the operative language (Ousterhout 1995). Currently some CAD producers offer solutions on the basis of GDL (Geometric Description Language) (GDL 2004): GDL allows, for instance, the import of catalogue elements into CAD systems via the Internet. However, the scripting language contained in GDL is not as open and extensible as Tc1/ Tk: An implementation of the operational language on this basis would be almost impossible. STEP (STandard for the Exchange of Product Model Data) is the informal description of ISO 10303 (International Organization for Standardization)—a whole family of international standards for the exchange, data management in databases and implementation (Haas, Ilieva, Kessoudis 2002). The German automobile industry tries to improve the quality of the data exchange by using the two dimensional subset STEP-CDS (Haas 1999). The IAI (Industry Alliance for Interoperability) attempts to provide a universal interoperable data basis for all phases in the lifetime of a building. The according data

A novel modelling approach for the exchange

125

model is the IFC (Industry Foundation Classes). This interoperability means that all planners involved would use this data basis. Currently the data exchange of a subset of the originally planned amount has been realised (Steinmann, Liebich 2002). State-of-the-art concerning STEP and IFC in civil engineering is the communication of the planners by the exchange of evaluated data. By contrast, our research project focuses upon unevaluated operative CAD models. XML (eXtensible Markup Language) is an open standard of the W3C (World Wide Web Consortium) for the format of documents. Is it suitable for the textual description of evaluated object models. However, the usage of XML as a language for the operative modelling would be rather tedious. 3.2 Recent fields of research in Germany Net-distributed processes are currently in the focus of research in Germany: These objectives are currently being explored in the Priority Programme 1103 “Netdistributed planning processes in Structural Engineering” of the German Research Foundation (Firmenich 2004). As many as 14 research projects are participating in the research programme. There are no overlappings between the opCAD project and the Priority Programme. 3.3 Traditional workflow scenario Available CAD systems have data structures that are optimised for their own tasks. A data exchange requires a transformation according to a common data scheme agreed upon. Very often, the data cannot be completely transformed in practice due to the incompatibility of the agreed data scheme. Even worse, the loss of information accumulates with each data exchange. This problem is explained below using the workflow of a typical co-operative scenario in the planning process: PlannerA: Local work (Fig. 1a) During project work planner A has reached an intermediate state MOA of the building instance. As agreed this version of the planning material shall be technically complemented by planner B. PlannerA: Generation ofthe exchange data (Fig. 1a) The CAD systems of planner A und B are incompatible with one another. For the data exchange planner A has to generate the exchange data Z0 from the native data MOA according to the agreed data scheme. Not all information can be stored: This information is described by the difference set MOA\Zo. (1) Planner B: Import of the exchange data (Fig. 1b) Planner B receives the exchange data Z0 and transforms it according to his own native data scheme to the data model MQB. Set Z0\M0B contains the non transformable information. The accumulated loss of information is described by set

eWork and eBusisness in architecture, engineering and construction

126

(2)

Figure 1a. Traditional workflow of the data exchange: Planner A. Planner B: Local work (Fig. 1b) Planner B complements the building version MQB by some technical issues and stores the product instance as MIB in the own native format. This data has to be transferred to planner A. Planner B: Generation ofthe exchange data (Fig. 1b) Planner B generates the exchange data Z1 from the native data M1B. During this process the information set M1B\Z1 gets lost. The accumulative loss of information is now (3) PlannerA: Import ofexchange data (Fig. 1c) Planner A transforms the exchange data Z7 into the own native data M1A. The information set Z;\M1A gets lost during this step. At the end of the workflow the set of the accumulated information loss is: (4) The problem of exchanging evaluated data The scenario illustrates the general problem of a cooperation based on the exchange of evaluated data i.e. the accumulated loss of data during the numerous required data transformations. Some of the projects involved into the current Priority Programme 1103 explore the applicability of versioned building instances in the planning process. Available results show that such systems will play an important role in future distributed applications. The exchange of versioned building instances is considered a currently relevant field of science because available specifications do not support this topic.

A novel modelling approach for the exchange

127

Figure 1b. Traditional workflow of the data exchange: Planner B.

Figure 1c. Traditional workflow of the data exchange: Planner A. 4 NOVELMODELLINGAPPROACH The proposed approach for the data exchange allows a version modelling. In version modelling, two completely different approaches are known. In a version-oriented model each single version is explicitly stored. In a change-oriented model the changes are stored instead of the versions: Versions have to be generated implicitly by applying the stored changes. In (Zeller 1997) it is shown that the version-oriented and the change-oriented approaches are equivalent in result. This is important for the proposed solution since it allows the exchange of versioned data. 4.1 Improvement of data exchange The result of the CAD processing is a new version of the building instance. The traditional data exchange is based upon the version-oriented approach (Figure 2) that can be described mathematically as a graph G:= (M;V)

(5)

The elements of the node set M represent versions, the elements of the edge set Mrepresent the relationships between two versions. Differences between two subsequent versions can only be obtained by a comparison between the two versions.

eWork and eBusisness in architecture, engineering and construction

128

This method leads to unsatisfying results because the semantics of the change between the two versions cannot be reconstructed. This thread is explained by an example from solid modelling. The consistent adjustment of a duct inside a building requires a recess r inside the wall w. Technically, this requirement has to be realized by a difference set operation wV. In a BRep model the semantics of the operation recess planning could not be reconstructed subsequently. In a CSG model, however, the operation and its semantics can be reconstructed because this information is part of the data structure. The solution approach presented is based upon the change-oriented approach (Figure 3): As in the version-oriented approach the node set M contains the versions. However, these versions need not be necessarily stored in an evaluated form. It should be noted that for performance reasons the

Figure 2. Version-oriented approach.

Figure 3. Change-oriented approach. versions could additionally be explicitly stored. Each edge Fhas assigned the change 5,y between the source version mt and the destination version mj. The original version m0 represents a special case: It is established by a change δx0 The changes δij can be explicitly exchanged applied to the empty virtual version between the users and can then be applied to versions.

A novel modelling approach for the exchange

129

The method described is state-of-the-art in Software-Configuration-Management (SCM): Changes that transfer a source version into a destination version are named a patch in SCM. This is described for instance in (Fogel, Bar 2002). The solution approach described is also based upon the change-oriented approach. However, there are serious differences between CAD and SCM. In SCM, changes are described by character strings to be inserted, overwritten or deleted at a certain position. Due to the complexity of the planning process, the required methods for CAD models cannot be specified easily. This task is in the focus of the opCAD research project. In the design and bidding phase specific proposals are developed frequently and have an important impact on the building contract. Figure 3 shows that two variants m1 and m3 have been derived from version m0. A second version m2 has been derived from variant m1. As is generally known the merging is a serious problem since the merged version has more than one input edge. For instance, version m4 has been merged from the two source versions m2 and w3 by the application of the two changes δ24 and δ34. State-of-the-art methods barely offer functionality to handle variants: The merging process cannot be reconstructed based on the destination version. In the proposed solution approach this is handled completely different. Instead of the destination version the operations to be applied upon the source versions are recorded. 4.2 Novel workflow scenario The proposed solution approach can both be used in an unversioned and in a versioned planning environment. Again, the scenario from chapter 3.3 is used to describe the change-oriented approach and its

Figure 4a. Novel workflow of the data exchange: Planner A.

Figure 4b. Novel workflow of the data exchange: Planner B.

eWork and eBusisness in architecture, engineering and construction

130

advantages over the version-oriented approach: PlannerA: Local work (Fig. 4a) During project work planner A has reached an intermediate state MQA of the building instance. According to agreements this version of the planning material shall be technically complemented by planner B. The change δx0 has been continuously and automatically recorded during interactive work: Data exchange between planner A and B (Fig. 4b) Not the evaluated version MQA, but the changes δx0 applied during interactive work of planner A are exchanged. By the help of the changes δx0 planner B generates the native building instance MQB in his software system. Eventually, some of the changes described in δx0 can not be realized in M05: The following set describes this information: VB = MOA \MO B (6) Planner B: Local work (Fig. 4b) Planner B complements the building instance M05 by his own technical components and stores it as version M1B. During work, the change δ01 between MOB and M1B is continuously and automatically recorded by the CAD system. Data exchange between planner B and A (Fig. 4c) Planner A still owns the version MQA. Therefore it is sufficient to exchange the change δ01 and to apply it on this version. From this operation the new version M1A evolves. If the change δ01 cannot be represented completely in the native model of planner A then the set of not transferable information can be expressed as: (7) It should be noted that the loss of information during the workflow process does not accumulate: The loss

Figure 4c. Novel workflow of the data exchange: Planner A.

A novel modelling approach for the exchange

131

Figure 4d. Novel workflow of the data exchange: Planner C. of information VB described in equation (6) is not contained in set VA described in equation (7). Data exchange between planner A and C (Fig. 4d) Since planner C does not own the evaluated version MQA, the changes of sequence (δx0, δ01) are applied subsequently to the empty version x: This leads to the version M1C. The set of untransferable information is (8) The loss of information does not accumulate since information that cannot be stored in the native system of planner B (set VB according to equation (6)) may be absolutely storable in the system of planner C. Advantages of the solution approach A change δij between two versions Mi and Mj can be formulated by the language to be specified in this research project. The change δij must not be transformed for the data exchange—it remains unchanged forever. The receiver of the change δij has an interpreter that issues the required actions to transform version Mt to version Mj. During this procedure a loss of information occurs if the result of a specific change cannot be represented by the destination model. However, the loss of information does not accumulate since the exchanged changes δij are conserved in their original form. 4.3 Change generation Available CAD systems support the recording of the applied operations: Normally, these journals are described by proprietary macro languages. Due to the absence of standardized languages, these journals could not be used for the data exchange. Inside a graphical user interface the journaling is a complicated task. An example for this estimation is the application of a digitized point inside a graphical window by the help of a pointing device. If this input is stored in device coordinates then the replay of this procedure in a window with another coordinate system leads to completely different

eWork and eBusisness in architecture, engineering and construction

132

results. It should be noted that these problems do not occur if the evaluated model is stored. 4.4 Other applications Operative modelling could also be applied for other problem domains. For instance, query and manipulation of the CAD data model could be handled by the help of the language for the operative modelling. In database technology the standardized SQL language serves to query and to process the relational data model. The users of the database system formulate their ad-hoc queries by the help of the SQL language (Date 2000). It is also possible to embed SQL programs inside application programs. Today, SQL is a complete programming language for relational database systems. Analogous, the language for the operative modelling could be used to solve problems in the CAD domain. A simple language would be highly desirable since existing modern programming environments can only be handled by specialists. The simplicity of the language to be specified is a major objective. Another important application is the archiving of operative CAD models by the help of the standardized language. According to experience the syntax and semantics of an unevaluated model does not change as frequently as in an evaluated model. Beyond that, the archived data can be interpreted by the users and not only by interpreters. 5 EXAMPLE The advantages of the proposed solution approach are shown in an example from 3D solid modelling. The available solid modeller ACIS (Corney & Lim 2001) describes solids with a BRep data structure. The BRep data structure describes the topology and the geometry of the solid boundary. The BRep data structure allows to distinguish between points inside the solid, points outside the solid and points on the boundary of the solid. The ACIS modeller allows to save and restore solids as a textual representation in so called SAT files (Standard ACIS Text). The ACIS modeller has an interface for rapid prototyping: The Scheme language allows to write programs to be executed by an interpreter. While the scheme language allows the formulation of a program for an unevaluated description of a solid, the SAT file represents an evaluated description of the solid.

A novel modelling approach for the exchange

133

Figure 5. Example from Structural Engineering.

Figure 6. Building description with the Scheme language. A specific example from Structural Engineering is shown in Figure 5: The example consists of a building b with a wall w1, a door d and another wall named w2. The resulting solid of the building can be represented by the following set operation: (9) Equation 8 can be formulated by the Scheme language. Figure 6 shows that the operations can be formulated in a program consisting of just four lines of code. In contrast, the evaluated description of the building’s solid is shown in Figure 7. It should be noted that the file consists of 288 lines of code–most of them were omitted due to shortening reasons.

eWork and eBusisness in architecture, engineering and construction

134

6 CONCLUSIONS At present, the exchange of information in civil engineering is predominantly based upon the versionoriented approach. Due to incompatible data structures, this transformation process is characterized by (1) a certain loss of information that (2) accumulates during each transformation process. In this paper another solution approach is proposed. The basic idea is that instead of an exchange of the building instance the changes that lead to this

Figure 7. Evaluated building description in a SAT file.

A novel modelling approach for the exchange

135

building instance should be exchanged. A prerequisite for the change-oriented approach is a method for the formal description of the changes. It is proposed that the changes should be described in the form of the executed operations: This concept is denoted as operative modelling. A programming language for the formal description of operative models is developed in the opCAD research project. In order to be used by the engineers this language should ideally be rather simple. It was pointed out that the novel approach has advantages over the traditional approach. In particular, the loss of data during the document workflow does not accumulate and the procedure can be perfectly used in a versioned environment. The proposed language for operative modelling could be used by engineers and programmers for the formulation of solutions to their specific technical problems. The language is considered to have advantages in the area of long term compulsory archiving. ACKNOWLEDGEMENT The author gratefully acknowledges the support of this project by the German Research Foundation (DFG).

REFERENCES Corney, J.& Lim, T. 2001. 3D modeling with ACIS. Stirling: Saxe-Coburg Date, C.J. 2000. An introduction to database systems. Reading: Addison-Wesley Eastman, C.M. 1999. Building product models: computer environments supporting design and construction. Boca Raton: CRC Press Firmenich, B. 2004. Product Models in Network Based Co-operation in Structural Engineering. In: Proceedings of the Tenth Conference on Civil and Building Enginering (ICCCBE-X). Weimar: Bauhaus-Universitat, Universitatsverlag Fogel, K. & Bar, M. 2002. Open Source-Projekte mit CVS. Bonn: mitp GDL2004. GDLAlliance. http://www.gdlalliance.com/. (l-Jun-2004) Haas, W. 1999. Datenaustausch und Datenintegration—STEP und IAI als Beitrage zur Standardisierung. Frankfurt: ACS Haas, W., Ilieva, D. & Kessoudis, K. 2002. Erfahrungen beim Einsatz Web-basierter Planmanagementsysteme im Planungsalltag. In: Bauen mit Computern—Kooperation in ITNetzwerken. Diisseldorf: VDI Verlag Ousterhout, J.K. 1995. Tcl und Tk: Entwicklung grafischer Benutzerschnittstellen fur das X Window System. Bonn: Addison-Wesley Serain, D. 1999. Middleware. London: Springer-Verlag Steinmann, R. & Liebich, T. 2002. IAI—Industrie Allianz fur Interoperabilitat: Stand der weltweiten Aktivitaten. In: Bauen mit Computern: Kooperation in IT-Netzwerken. Dusseldorf:VDIVerlag Zeller, A. 1997. Configuration Management with Version Sets. Dissertation am Fachbereich Mathematik und Informatik der Technischen Universitat Braunschweig

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Integration of product models with documentbased information T.M.Froese University of British Columbia, Vancouver, BC. Canada ABSTRACT: Recent trends in information technologies for architecture, engineering, construction, and facilities management rely of model-based applications and interoperability. Yet even in the most optimistic scenarios for these building information model approaches, much project information will remain as traditional unstructured documents. There have also been many information technology advances to support documentbased information, but only limited work to inter-relate these two significant bodies of project information. This paper introduces the issue of integrating model-based and document-based information, and in particular, the need to synchronize human and computer communication channels in project transactions. The paper then outlines a series of technical approach: cross-referencing, text processing and data mining, hybrid document types, and a presentation layer for building information models.

1 INTRODUCTION Much of the recent research and development into information technologies for the construction industry has focused on model-based systems. These systems use structured data models of facilities and their associated construction projects to support a range of application tools and the integration of information across the project lifecycle. However, in even the most optimistic scenario for model-based approaches, the vast majority of current project information exists in the form of unstructured documents. At present, there is very little linkage between information technologies for working with unstructured document-based technologies and model-based technologies. This paper discusses issues relating to the integration of these two branches of information technology. After introducing model-based and document-based technologies, the paper will show how a consideration of human-computer communication channels leads to the requirement for synchronized model-based and document-based technologies. Next, the basic techniques for establishing linkages between the two technologies are described. These include references from an object-oriented project model to external documents, or references to model objects from document meta-data. Text processing approaches will be discussed as another relevant approach to integrating the two technologies. The paper will also discuss specific types of documents that can span between unstructured document-based and model-based approaches, such as 2D CAD and project specifications. The paper will then discuss issues relating to the generation of static and dynamic documents from project data models in the form of a presentation layer

Integration of product models with document based information

137

component of model-based technologies. This presentation layer can help ensure that the receiver of a project data model receives the specific interpretation of information via an exchange of a data model that the originator intended to send. This could have a significant impact on enabling the use of model-based approaches for carrying out specific information transactions. This paper lays out a series of approaches to the integration of model-based and document-based information. Our work is in the early stages of forming a research prqject, so this paper outlines the technical issues, but does not neport detailed literature search or research results. 2 MODEL-BASED TECHNOLOGIES Many of the leading edge information technologies emerging to support the construction industry rely on model-based techniques. In general, we consider model-based technologies to be any IT that organizes information into elements associated with semantic meaning that reasonably corresponds to the semantics of the actual construction project—i.e., the data objects model the real-world objects. The primary example of this is the move from purely “geometric” CAD-where the system works with geometric primitives (lines, etc.) and it is left to users to interpret these primitives as real-world elements (walls, etc.)–to object-based CAD systems where both the system and the user work with elements that represent walls, slabs, doors, windows, etc. Any software tool that uses model-based techniques, then, can be described as a model-based application. Thus, object-based CAD, estimating, scheduling, and structural or HVAC analysis software can be model-based, since they organize their information around elements that correspond to real-world elements (e.g., building components, costs, tasks, beams, and heat sources, respectively). On the other hand, word processor documents, photographs, spreadsheets, and traditional CAD are generally not modelbased since they organize their information around elements that do not correspond to real-world elements (e.g., words, raster images, cells, and lines, respectively). Moreover, there is a trend towards comprehensive and integrated model-based approaches, where a variety of model-based tools can exchange data and collectively develop detailed, multi-purpose data models of construction projects. The key issue here is that, since the software captures some of the semantic meaning of each element of information, the potential exists to inter-relate all of this information. This integration can greatly leverage the value of the individual applications and data sets. Ultimately, this could lead to an approach where most project information and communication is centred on a virtual project model that is developed and managed in parallel with the development and management of the actual physical project. This approach, referred to by various terms such as building information models and virtual design and construction, requires both modelbased applications and model-based interoperability. Model-based interoperability, in which project data models serve as a common language for exchanging data between applications, is typified by the Industry Foundation Classes (IFC) data standard (International Alliance for Interoperability, 2004; Kam et al., 2003).

eWork and eBusisness in architecture, engineering and construction

138

3 DOCUMENT-BASED TECHNOLOGIES In spite of the interest in model-based technologies, even the most optimistic scenarios must concede that a large proportion of project information will remain in the traditional form of unstructured documents for many years to come. Here too, there have been significant advances in supporting information technology. The vast majority of project documents are now produced electronically using various computer applications, while the consumption (viewing), transmission and storage of documents are a combination of electronic and paper-based. Electronic document management systems provide a comprehensive range of features to manage project documents, including conversion between paper and electronic documents (printing, scanning, and character recognition), sharing and distribution, storage, versioning, indexing and searching, tracking, etc. From an IT perspective, these documents contain unstructured data, yet much of the IT used to support document management makes use of document metadata, or structured data about documents. Document meta-data can range from simple information such as document type and creation date (which exists for virtually any electronic document), to extensive industry-specific information that link documents to related people and roles, type of work, contractual relationships, project phase, etc. Again, interoperability becomes important and standards have been developed. Examples include the Dublin Core as a general document meta-data standard (Dublin Core Metadata Initiative, 2004) and various construction-industry-specific meta-data standards (International Electrotechnical Commission, 1999). While meta-data provides opportunities for organizing and managing documents, it can be difficult to capture and maintain meaningful meta-data, particularly if it requires additional data entry from end users. Other information technology trends that are not directly related to document management per se, but that are closely related, include project web portals (which act as a central collaboration site for project teams and often include extensive document management features), and workflow management systems (which can be used to define typical work processes, manage the assignment and progress of tasks, and automate much of the information handling requirements). 4 COORDINATING HUMAN AND COMPUTER COMMUNICATION CHANNELS Figure 1 illustrates key elements and information interfaces in an IT environment. Within the construction industry, most design and management tasks are fairly well-supported by computer tools. However, these are not isolated activities–rather they are highly collaborative, involving large numbers of project participants operating in a highly fragmented and dynamic environment. Correspondingly, IT solutions involve not only stand-alone computer applications, but must be viewed as elements in an overall technical and social system. Within this system, information flows between individual users and their computer– based tools (data entry from the user to the computer, and data interpretation from the computer to the user). Information also flows between users (as direction communication—i.e.

Integration of product models with document based information

139

Figure 1. Elements and information interfaces for an individual participant and the overall system of a construction project. face-to-face or telephone conversations—or via exchanged documents), and between different computer applications (as shared computer data). At present, information sharing typically involves a project participant entering project data into a computer application to produce useful project information, creating a paper or electronic document containing the information, and distributing the document to others (via mail, fax, courier, or e-mail), after which other participants interpret the document and re-enter relevant information into their own computer applications. Thus, there is little systems-integration and interoperability, and the data exchange that does occur is inefficient, time-consuming, error-prone, and a barrier to greater computer functionality. The inefficiency of this approach to exchanging information between computer systems (from computer application to human-interpreted documents and back into a second computer application) is improved by using direct computer-to-computer data sharing. However, it is not sufficient to rely on computer-based data sharing alone, since this creates the opposite effect. A user working with one application may interpret some project information as having certain significance for the project (e.g., the design doesn’t meet certain user requirements, the costs are over budget, or the work method is infeasible). If the same project information is successfully communicated to different computer application used by another project participant, there is no assurance that the second user will interpret the same information in the same way. That is, they may have the same data available to them, but they may not recognize the design, cost, or work method problems. As a further example, a project architect and a general contractor could collaborate to develop a detailed and complete IFC-based building information model for a building project. The architect might then send the product model to the structural engineer to inform them of some design changes, or the general contractor might send it to a subcontractor to bid on a work package. In both cases, the product model might be

eWork and eBusisness in architecture, engineering and construction

140

extremely beneficial, e.g., effectively feeding data into structural analysis or estimating software. However, the building model can be a large data set that is beyond the scope of any single application to effectively convey to the user. With the building model alone, the structural engineer might not clearly understand what parts of the building had changed, why, and what additional requirements existed; the subcontractor might not clearly understand what scope of work was included in the work package. For the overall communication to be effective, both the computerto-computer data sets and the humanto-human interpretation of the data must be exchanged. This illustrates the fact that efficient project communication must take place along all of the communication channels: human-to-human, human-to-computer, and computer-tocomputer. Furthermore, these different communication channels should be coordinated— in effect, a project communication from one user to another could say “here is a data set and here is a document that describes how I expect you to interpret this data”. Previous research into model-based interoperability has not addressed this coordination of human-based and computer-based communication channels. Our view is that a successful solution to project information management requires this type of coordination, and that this is achieved by inter-relating the model-based and documentbased information technologies. The remainder of this paper introduces a variety of basic technical approaches for establishing this inter-relationship. 5 CROSS-REFERENCING Perhaps the most basic approach to integrating model-based and document-based technologies is the use of cross references from one to the other. In most cases, documents can be identified by some type of unique identifier. Project model standards such as the IFCs include mechanisms to associate a reference to an external document (via the document identifier) with any project object. If, for example, the document is stored in an electronic document management system on a project collaboration web site, this reference information could allow the user of a CAD system to select a component of the building in the CAD system and directly access any associated document (such as the manufacturers specifications for a window). A similar mechanism can be used in the reverse order, where documents refer to individual objects in a project model by their unique ID. This reference could be embedded in the unstructured document itself (similar to including a hyperlink URL in a word processor document), or it could be part of the structured metadata associated with a document (e.g., request-for-information notices stored in a project collaboration web site could be indexed according to the building components in question). This approach of representing cross-references is technically straight-forward, yet it provides a sufficient representation for various types of computer applications to create quite effective integration of model-based and document-based information. Some of the challenges include capturing the crossreference relationships in the first place, and managing a large collection of cross-referenced project information. Another challenge is that this approach creates a relationship between a specific model object and a specific document, from which systems may need to infer more specific or more general relationships. For example, a relationship may be established between a change-order

Integration of product models with document based information

141

notice and a specific room in a building; yet the document should be retrieved if a user is looking for all change documents associated a specific wall within the room, or associated with the entire floor of the building. 6 TEXT PROCESSING AND DATA MINING One opportunity to link model-based and document-based information is to use text processing techniques on documents (or other types of data mining techniques on other types of data) to extract significant words and a limited amount of semantic information from the documents. This semantic information can then be associated with the documents as anything from a set of simple keywords to a structured data model of the document content, which could then be mapped to other model-based data sets. Text processing and data mining of construction documents have been examined by a number of researchers (Schapke et al. 2002; Caldas and Soibelman, 2002). 7 HYBRID DOCUMENT TYPES Certain systems represent information in a manner that spans between model-based and unstructured-document-based (i.e., hybrid approaches). An example would be a specification-authoring system that allows the user to organize the specification documents for a project into a highly structured hierarchy of sections. Each section is made up of a passage of unstructured text interspersed with certain words, phrases, names of products, etc., that are structured data fields linked to an underlying data model and database. In an integrated scenario, these data fields could be mapped to elements in an overall project data model. We describe this as a hybrid type of document since the information is only complete and usable when the unstructured text and the structured data fields are considered together. 8 PRESENTATION LAYER Section 4 described the need to communicate both the computer-to-computer data sets and the human-to-human interpretation of the data as part of an effective transaction. For model-based information, this might be done by deriving document-based versions of the model data and incorporating these documents within the model itself. We describe this approach as a presentation layer within the model. The documents could be produced by any application that can produce a useftil view or presentation of the information contained in the data model, possibly by reading parts of the data model and requiring additional effort from a user to manipulate, interpret, and supplement the model data. A simple example would be a text document that lists the key changes made between two versions of a data model. Another example would be a CAD program that reads the data model and uses the model geometry to produce a 2D cross-section of a segment of a building, which a designer then embellishes to produce an annotated design detail

eWork and eBusisness in architecture, engineering and construction

142

drawing. A final example would be a bill of quantities report in which certain quantities are linked directly into an enumeration of objects within the data model. Presentation layer documents can be either static (capturing a specific view of the data set at a specific point in time), or dynamic (presenting a specific view of the data that is automatically updated when the data model changes). In a static approach, for example, the 2D design drawings described above might be written to an acrobat (PDF) file embedded within the data model. In a dynamic approach, an XSLT template document could be created that would produce an HTML version of the bill of quantities report (mentioned above) at any time by applying the template to an XML version of the data model. With any of these approaches, the presentation-layer documents give snap shots (specific views) of the model data intended to convey specific information for specific purposes in human-to-human communications that accompany model-based transactions. 9 AN OVERALL SCENARIO The following describes a possible scenario that would incorporate many of the issues and techniques discussed in this paper: – On a given building construction project, many of the key participants have agreed to use IFC-compatible model-based design and management tools. – A project web portal is adopted that incorporates strong document management features as well as a model-server that can host a shared IFC building information model and interface directly with participant’s IFC-enabled software applications. – One company acts as the information manager on behalf of the overall project, with one individual acts as a project information officer. – Throughout the project, participants make regular use of the portal, contributing project information into the portal and accessing information from the portal. – Many of the information transactions are ad hoc in terms of who is using the information, what information is used, and for what purpose. However, many other transactions follow formalized transaction templates or specifications (e.g., requests for information, progress payment claims, etc.). – The formalized transaction templates specify the content and form of information to be included in the transaction. These can include complete or partial building models as well as various types of documents. – Objects within the building information model and documents within the document management system cross-reference each other, and tools on the project web portal allow users to navigate between these different types of information. – The data required to create these cross references is acquired from user input, is inferred from the context in which the information is entered into the system, and is captured from within certain documents from some text processing capabilities built into the portal site. – At any time, the entire building information model (or a specific subset), can be exported from the portal site. This model can include the documents embedded in (and cross-linked to) the model.

Integration of product models with document based information

143

10 CONCLUSIONS This paper has argued that model-based information technologies and document-based information technologies should be integrated and used to support transactions that combine human-to-human and computer-to-computer communications. The technical approaches outlined to achieve this integration include cross-referencing, text processing and data mining, hybrid document types, and a presentation layer within data models. Solutions based on these approaches need not be complex, but some attention to this issue and recognition within an overall information management approach could significantly improve the effectiveness of project information and communication approaches. REFERENCES Caldas, C. and Soibelman, L. (2002), “Automated Classification Methods: Supporting The Implementation Of Pull Techniques For Information Flow Management”, Proceedings IGLC10, Gramado, Brazil, http://www.cpgec.ufigs.br/norie/iglc10/papers/99-Caldas&Soibelman.pdf Dublin Core Metadata Initiative. Dublin Core Metadata Initiative (home page). http://dublincore.org/(accessedJune3,2004). International Electrotechnical Commission (1999), Project IEC 62045 Ed. 1: Management data (meta data) associated with documents URL: http://tc3.iec.ch/txt/169.htm(accessedJune3,2004). International Alliance for Interoperability (2004), IAI International Home Page, http://www.iaiinternational.org/iai_international/ (accessed June 3, 2004). Kam, C., Fischer, M., Hanninen, R., Karjalainen, A. and Laitinen, J. (2003), “The product model and Fourth Dimension project,” Electronic Journal of Information Technology in Construction, Vol. 8, pg. 137–166. Schapke, S.-E., Menzel, K., and Scherer, R. (2003), “Towards Organisational Memory Systems In The Construction Industry”, eSM@RT and CISEMIC Conference, http://cib.bau.tudresden.de/~sven/Publications/20020903_PubFinal_eSmart2002_SES.pdf

eWork and eBusiness in Architecture, Engineering and Construction–Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Aligning IFC with the emerging ISO10303 modular architecture. Can AEC community take advantages from it? Ricardo Jardim-Gongalves‡, Fatima Farinha*, Adolfo Steiger-Garcao‡ ‡Universidade Nova de Lisboa, Faculdade de Ciências e Tecnologia— UNINOVA, Portugal *Universidade do Algarve–IST, Portugal ABSTRACT: International Alliance for Interoperability (IAI) is a world wide consortium aiming to define the requirements for software interoperability in the AEC/FM industry. The deliverables of IAI are the specifications of Industry Foundation Classes (IFC), an object oriented software library for application development. IFC model is described in EXPRESS, and based in the general architecture oflSO 10303–STEP to describe its reference model. However, during the last few years, STEP has been reorganised adopting now a modular architecture, already with encouraging results. Should IFC be aligned with the emerging ISO10303 modular architecture, getting AEC community advantages from it? This paper discusses a modular architecture for IFC, aligned with the work developed for ISO10303, examining the benefits that such proposal can bring to AEC. The paper catches results from the research developed within CEN/ISSS and IMS projects close to ISO TCl 84/SC4, when developing one of the first modular STEP Application Protocols, and extends them to investigate the potentialities of this new architecture on IFC.

1 INTRODUCTION Nowadays, business success depends on the seamless integration of enterprises’ internal processes and relies on collaborations with outsiders. In the advent of electronic data exchange, heterogeneous data models and processes need to be integrated in order to provide interoperability between systems. This situation has been identified hard to achieve, mainly because each application adopts its own distinct data structure and semantics (Chen, 2000). The principal recognized difficulties preventing interoperability between applications are in its genesis problems related with: (i) data model compatibility and mapping; (ii) different languages and methodologies for model representation; (iii) correctness in the semantics of the data exchanged; (iv) readiness for model reusability and (v) accurate conformance and interoperability checking between applications (Jardim-Goncalves, 2001).

Aligning IFC with the emerging

145

The adoption of a common standard model, e.g., IFC or STEP Application Protocols, could help face this problem. However, these models should not be completely static in order to enable reusability and dynamic adaptation along time. This flexibility requires the definition and agreement of common semantics, to represent uniformly the meaning of the data to be instantiated and exchanged between applications. Building and Construction (B&C) industry involves a long process direct at the satisfaction of clients and customers’ needs through the provision of quality products that fulfil their purpose at a reasonable cost. It comprises complex activities that involve the combined efforts of several specialists from different disciplines. Contrary to what is seen in other manufacturing industries, the B&C’s artefact is almost always a oneoff product. This main difference between the creation of a single item and mass production has led the adoption, by B&C community, of a conservative technological attitude and progress has not been as fast as in other industries (JardimGoncalves, 2003). The life cycle of an artefact is long and normally it involves a large number of participants with different experience and knowledge, often located in different geographic areas. In B&C the life cycle of a product is basically a sequential process comprising various stages in which the following stage does not begin before the previous one is concluded. Nevertheless, B&C projects allow concurrency between the different stages. For example, escavation can begin before the design and planning stage is fully completed, allowing a reduction of the overall project time, while phased occupation can begin before external paintings completion, providing an earlier return on investment. If one considers, for instance, the design and planning stage, we find the processes used are essentially sequential. However, concurrent procedures can be adopted easily in large numbers of situations, even for small projects. The major obstacles identified to block such an approach are caused by two main facts: 1. Engineering data is not interoperable; 2. Interaction between different participants is neither represented nor correlated. The need of a unified and interoperable model that integrates all the information and knowledge related to the different stages and that allows participants to access all the information is a requirement. In this scenario, the end user, can directly access to the system’s data or do it through the project manager, controlled by the system’s managing applications and rules. However, for instance for practitioners in these industrial environments, time and material planning is still very often done in a manual process at the construction site in a standalone basis, mostly assisted by data received by phone calls or by fax machines (paper support). Regarding the utilization of state-of-the-art ICT in the B&C industry, adherence is still very poor (Filos, 2000) (prodAEC, 2004). Most established ways are concentrated on the individual use of CAD tools, scheduling/planning applications, and automation of certain pre-fabrication processes.

eWork and eBusisness in architecture, engineering and construction

146

Each application usually runs isolated, without any capability to exchange automatically data, driving companies to reach proprietary dependent solutions, without a complete integration of applications, and product, process and business data. Also, little work has been undertaken in the development of overall control architectures for building sites, whereas the development of such control architectures for other industrial sectors has advanced significantly during the last number of years. The implementation of computer integrated environments including design, planning, production, business and control to an outdoor building site can then be seen as a top stage of ICT integration into the construction industry. Reengineering is the fundamental key to rethinking and redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed (Blockley & Godfrey, 2000). The existence of effective seamless ways to exchange information (schedules, resources, materials, cost, cash flow) between the different parties involved in building and construction projects is a critical success factor. It can avoid projects’ time and costs overrun and assure better quality. Awareness of these facts twelve companies interested in being able to work together without being concerned about the applications each one were using founded the International Alliance for Interoperability (IAI). The key deliverable is the IFC Object Model (IAI/IFC, 2001) that provides a formal specification of requirements that can be used by software developers in creating compliant applications. IFC model, described in EXPRESS (ISO10303–11, 1994) is based on previously work done by the International Standards Organization Technical Committee 184, Sub Committee 4 (ISO TC 184/SC4, namely, ISO10303–1—STEP (STandard for the Exchange of Product model data). Both organizations are working in liaison on developing neutral definitions of information that can be shared electronically, where STEP is concerned with all industry sectors including B&C whilst IAI is vertically focused on B&C industry sector. 2 METHODOLOGYFORDEVELOPMENT OF AN APPLICATION PROTOCOL (AP) STEP publishes a proposal for a methodology for development, implementation and validation of an open architecture for exchange and share of product data, together with a set of public data models identified as Application Protocols (APs), i.e., data models valid to be used in the scope of one vertical application, ready to be adopted by the industry and covering the most important activities of the manufacturing process and product life cycle. The development of an Application Protocol (AP) can be described following a methodology in “V”. Figures 1 and 2 depicts such a methodology in two different views, respectively: 1) time vs. industry/ standardization bodies, and 2) level of implementation vs. application context. The Application Activity Model (AAM) is in the first phase of the development of one AP. The purpose is to identify the relevant activities that are carried out in the scope of an AP, together with the applicable information flow between them.

Aligning IFC with the emerging

147

An AAM consists of a structured graphical representation of the main activities defined in the scope of an AP, providing a global vision of the activities to be performed in the system, together with the information flow, actors, processes, inputs and outputs.

Figure 1. “V” approach for AP development: time vs. industry/standardization bodies.

Figure 2. “V” approach for AP development: level of implementation vs. application context. IDEFO/SADT is an accepted methodology to develop AAMs that is to be developed with strong connection with the end-users, e.g., industrial experts. Based on the AAM, the modeling experts workingtogether with the end-users develop and validate the Application Reference Model (ARM). The ARM is the data model that

eWork and eBusisness in architecture, engineering and construction

148

describes the structure required to represent the information in the scope of the AP, stating the information requirements and constraints in the application context. This model is expressed using a normalized modeling language (e.g., ISO10303–H EXPRESS), and should be structured using entities, attributes, assertions and relationships described for easy understanding by the industrial experts. Figure 3 depicts the architecture for the development of one AP at reference level. The Application Integrated Model (AIM) represents the implementable AP, when it interprets the ARM using normative resources. The AIM acts as a formal data model which defines the structure and content for the neutral data exchange (Figure 4). Interpretation is a major task to be done by standardization experts who map the industrial concepts at ARM level with the available standard entities, released as standard Integrated Resources (IRs). IRs are sets of entity schemas that were identified as a common concept for many industrial APs.

Figure 3. Architecture for AP development at reference level.

Aligning IFC with the emerging

149

Figure 4. Architecture for interpretation of one AP. These resources were developed by standardization experts, and made available ready for reuse, representing generalized models suitable to be adopted across many APs as the basement of a platform for interoperability, extended to satisfy the information requirements and constraints of an application reference model, within an Application Protocol. For the development of the AIM, when the IR concept is identified at one AP’s ARM level, the respective IR should be adopted and integrated in the implementable model through a mapping process. The mapper will be the one to match and extend the semantics from the model at ARM level and to the AIM, reusing the IRs. When a group of IRs that is suitable for reuse by many Aps is identified, it can be interpreted and integrated in an “application oriented super-IR”, identified as an Application Interpreted Construct (AIC). An AP can be organized in many views, representing sub-scopes of usability depending on the extent and objectives of its usage, i.e., the AP’s Conformance Classes (CC). Each CC is defined selecting a set of the ARM’s entities that cover a specific subscope of the AR For example, a CC from an AP for geometrical representation can be the one that just supports 2D geometrical representation.

eWork and eBusisness in architecture, engineering and construction

150

Figure 5. Global architecture of one integrated AP. The organization of an AP in CCs is important for certification of the software implementing the AR This implies that one application to be compliant with an AP is not forced to fully implement it. It can only implement one or more of its CCs, and only conform to them. Figure 5 depicts the complete integrated architecture established for development of one AP, showing the major roles and relationships between its components. This architecture is divided into two major blocks. The lower level, representing the implementation specification of the model, includes the AIM, built using selected standard IRs and AICs. This level is independent of the industrial scope. The upper level represents the conceptual specification of the AP. This level uses the AAM defining the AP’s application context, scope and functional requirements as the

Aligning IFC with the emerging

151

entry point for the development of the ARM, which specifies in a formal modeling language the application domain and information requirements for electronic data exchange. The ARM is built with several schemas of entities, usually known as Application Objects (AOs) that can be clustered by functionality matters, defining Units of Functionality (UoFs). This level is dependent on the industrial scope of the AP. The CCs are defined to organize the AP in sets of conformance requirements for implementation. To certify an application as compliant with a complete AP, or to a set of CCs of an AP, standard Abstract Test Suites (ATS) need to be defined for verification and validation tests. These ATSs should be also part of the standard AP. The two described blocks of this architecture are linked through a mapping procedure that describes the reference path for complete semantics matching between the industrial model representation and the neutral independent one. 3 MOTIVATIONS FOR ADOPTION OF MODULARAPS An Application Protocol represents a referential standard model within a specific application scope. However, the typically large dimension of an AP leads to complex models, which become standards of difficult reusability. They need to be organized in well defined and simple scope limited modules. To respond to this need, modularization is an increasingly important research activity related to the development of standards. It is expected to be a major contribution for supporting solutions for interoperability. Application modules were recently introduced to the STEP architecture and are considered the key components for the new generation of APs, intending to make them more interoperable, cheaper, quicker to develop, and easier to understand and to manage. In this new architecture, each module is seen as an “atomic self-contained AP” with a respective reference and interpreted model (ISO10303, 2004). The inclusion of the application reference model in a module is a major clue in this modularization approach, because it extends the application interpreted construct (AIC) concept of the classical STEP architecture towards a representation easier to understand by the user, keeping the implementation advantages for the implementer (ISO10303,2001) (ISO10303, 2002). Thus, the need to create flexible models to support very large combinations of systems can be sustained by a set of selected application modules, as the basis to develop a complete new AP. When compared with most of the existent Application Protocols, typically complex and in compacted big models, the granularity of this novel standard architecture makes the systems representations more flexible, interoperable and independent, to better support new model representations and respective implementations. This is a major advantage that provides specialized and autonomous structures prepared to be reused to support the emerging industrial and business modeling requirements. Figure 6 depicts the architecture of a modular AP.

eWork and eBusisness in architecture, engineering and construction

152

Figure 6. Architecture of a modular AP. 4 IFC MODEL ARCHITECTURE The IFC model architecture has been developed using a set of principles governing its organization and structure (IFC, 1999b). These principles are focused on basic requirements for interoperability between applications operating in the B&C industrial sector and respective integration of data, and provide a structure for an integrated model together with a suitable framework for exchange and sharing of information between different disciplines within the AEC/FM industry. This architecture provides a structure identified as the “model schemata”, and it has four conceptual layers, which use a strict referencing principle. Within each conceptual layer a set of model schemata are defined. The first conceptual layer is the resource layer. It provides resource classes used by classes in the higher levels. The second conceptual layer, i.e., the core layer, provides a core project model. This core contains the kernel and several core extensions. The interoperability level is the third conceptual layer. It provides a set of modules defining common concepts and objects across multiple application types and AEC industry domains. Finally, the fourth and highest layer is the domain layer. It provides a set of modules tailored for specific AEC industry domain or application type. There are three possible ways to share data using IFCs. These are: 1. By creating a physical file of information that may be shared across a network, by email or on a physical medium such a floppy disk. The EXPRESS language specification view of the IFC Object Model determines the structure of the file and the syntax of the file is determined by ISO10303 part 21, or more recently in XML; 2. By placing information in a database which has an interface defined according to the ISO10303 part 22 (Standard Data Access Interface) for putting in and getting out data. The EXPRESS language specification view of the IFC Object Model determines the structure of the information sent to or received from the database. Presently, a number

Aligning IFC with the emerging

153

of software applications work using shared databases (also known as project model servers); 3. By using software interfaces that can expose the information content of defined groups of attributes within an object Software interfaces allow for direct communication between applications without the need for an intermediate file or database.

5 DISCUSSION Both STEP and IFC architectures are based on EXPRESS. However, IFC is simpler, though it does not consider the Interpreted Model, having their implementations at the reference level. The existence of an unique reference model, makes the IFC model easier to implement, and to reuse its model’s components. Modularization is a major achievement in the STEP’s architecture, because it will allow having modules representing atomic aspects of the product life cycle that already includes the respective interpretation. This situation facilitates the reuse of such existent components/modules, enabling an immediate implementation at AIM level. Module’s development also obligates to have such components independent of each other, acting as an autonomous atom. Therefore, this Atomic Modules, can circulate along the applications adopted for its product life cycle, with independence, and using bounded information description, i.e., without the necessity to bring attached the complete global model (e.g., AP). IFC is already developed in a well structured architecture, in many layers, each one composed by a set of schemas, called modules. However, these schemata have strong dependencies among the others, not having yet the required “atomaticity”. This makes difficult potential extensions of the IFCs, as part of future releases of IFC or even by external parties interested in such extensions, i.e., joining of external modules. The reuse of the existent modules for the creation of new schemas at Application Domains layer will be easier to develop using the proposed approach, i.e., complete modularization will enable dynamic development of new modules, based on the IFC modules, i.e., extension or reuse, specially based on the models in the Kernel and Resources layers. This dynamism will help to face the heterogeneity problem of an application willing to use the IFC modules, when IFC cannot offer yet an integrated built-in complete solution as intrinsic part of its standard. Indeed, it will not be possible to cover all requirements foreseen by all applications operating in the B&C area, including their many applicational views. In such way, and in a case by case basis, each application can adopt IFC modules, and when necessary to create new IFC-based modules, through extension from reuse of the existent IFCs’. AEC community can take important advantages from this strategy, allowing sustained growing and increasing of the existing IFCs, having it as an open standard platform, where external contributions will be absorbed, though developed and validated according the IFCs architecture and quality assurance rules. With time, and with such distributed effort, IFCs would be more and more complete, and adopted by the users and application developers.

eWork and eBusisness in architecture, engineering and construction

154

ACKNOWLEDGEMENTS The authors would like to thank all the national and international organizations that supported the international projects that resulted in the development of framework presented in this paper, the European Commission, CEN/ISSS, Ministry of Industry of Portugal, IPQ—Portuguese Standardisation Body, ISO TC184/SC4. Also, the authors express recognition for the project partners and our colleagues that work and contribute in the international research and development projects developing the modular ISO10303 (STEP) AP236. To Ricardo Olavo, for his assistance at UNINOVA in the modularization activities. REFERENCES prodAEC, 2004, http://www.prodaec.net/. Blockley, D. & Godfrey, P. 2000. Doing it differently: Systems for rethinking construction. UK: Thomas Telford. Chen, Q. 2000. Inter-enterprise collaborative business process management. Technical report, HP Labs Palo Alto, http://www.hpl.hp.com/techreports/2000/HPL-2000–107.pdf. Filos, E. 2000. Moving construction towards the digital economy. In Goncalves et al. (eds.), 3rd ECPPM conference, Lisbon, pp. 3–10, September 2000, Rotterdam: Balkema. IAI/IFC 2001. International Alliance for Interoperability. Industrial Foundation Classes. http://www.iai.org.uk/. IFC 1999a. An Introduction to the International Alliance for Interoperability and the Industry Foundation Classes. March 1999, IAI. IFC 1999b. IFC Object Model Architecture Guide. March 1999, IAI. ISO 10303, 2001, Standard for the Exchange of Product Data (STEP), ISO TC184/SC4 N1 113, Guidelines for the content of Application Protocols that use application modules, International Organization for Standardization. ISO 10303, 2002, Standard for the Exchange of Product Data (STEP), ISO TC184/SC4, N535, Guidelines for the development and approval of STEP application protocols, International Organization for Standardization. ISO 10303, 2004, Standard for the Exchange of Product Data (STEP), ISO TC184/SC4, Parts Ixxx—Application Modules, International Organization for Standardization. ISO 10303–1 1994. Part 1—Overview and Fundamentals Principles. International Standardization Organization. http://www.tc184-sc4.org/. ISO 10303–11 1994. Product data representation and exchange Part 11: Description methods, The EXPRESS language reference manual. International Standardization Organization. ISO 10303–21 1994. Product data representation and exchange Part 21: Implementation methods, clear text encoding of the exchange structure. International Standardization Organization. Jardim-Gonçalves, R. & Steiger-Garção, A. 2001. Agile Manufacturing: 21st Century Manufacturing Strategy, Chapter 48: “Putting the pieces together” using standards. Elsevier Science Publishers, pp. 735–757. Jardim-Gonçalves, R. Farinha, F. & Steiger-Garcao, A: 2003, A metamodel based environment to assist integrating one-off production in B&C, International Journal of Internet and Enterprise Management, Vol. 1, N° 2, April-June 2003. eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Optimization of project processing in the steel construction domain E.Holtzhauer & H.Saal Lehrstuhl für Stahl- und Leichtmetallbau, Karlsruhe, Germany ABSTRACT: Today, the main part of the work in the A/E/C domain is supported by computer applications, reaching from pure building applications to general company administration software. Because of the diversity of occurring tasks within the company as well as within the construction project, many problems in regard to data and information management have to be solved, which still are the purpose of current research activities. This paper deals with the requirements of the German steel construction industry and proposes an approach to optimize the project processes in the sector, combining existing partial solutions.

1 INTRODUCTION The A/E/C domain is characterized by the required cooperation between partners from very diverse fields of activity, knowledge and terminology. This phenomenon is also reflected by the applied software tools which were developed for one specific application area. The design and construction process of a building is project-oriented, and thus associates those partners in heterogeneous workgroups within the companies as well as within the whole project. The different views on the project induce problems with regard to information integrity and distribution. The latter are emphasized by parallel planning steps on one and the same object, which are often necessary due to time pressure. Finally, losses due to inefficiencies in project processing in the building industry are estimated up to 40% of the total costs. Hence, the optimization of the project communication and the rationalization of the project processes reveal a big potential to ensure the competitiveness of enterprises within the sector. This cognition is mirrored in the past and current developments of IT-technologies for the A/E/C domain. On the basis of the requirements of the German steel construction companies, the specifications of an integrated project processing system are elaborated. Because of the numerous existing software standards, the number of new applications should be kept minimal. Therefore, the actual state of the art in design and construction practice and developments of current research activities are analyzed. From there on, a methodology for an optimized project processing—especially for steel construction domain—is proposed. The model is then evaluated with regard to its applicability in time and for other A/E/C-domains.

eWork and eBusisness in architecture, engineering and construction

156

2 REQUIREMENTS 2.1 Project and company views The organization of a company is human-centered, i.e. its structure is subdivided in function of the competences and tasks of a department. Therefore one person or at least one division work simultaneously on several construction projects. All systems to support project processing should take this organizational structure in account (Katranuschkov et al. 2002). The tasks of the diverse departments are generally supported by incompatible and fragmented software applications, which rely on different concepts and database structures. The German steel construction industry (DStV 2004) considers the creation of integrated solutions which interconnect both all company actors and all project partners as well as their respective software one of the most important challenges. The latter should on one hand be able to represent the entire operational and organizational course of business in the company and handle all project-oriented processes centrally. On the other hand, the mentioned applications should be able to integrate themselves in the project context. This would allow consistent information flows within the company for the diverse departments, e.g. marketing, project-management, technical design, etc. and over the project for the diverse involved partners, e.g. architect, civil engineer, steel construction. 2.2 Data and information management Because of different terminologies and software tools, the main difficulty of integrated solutions consists in managing data and information. From the company’s view, the shared data has to be kept consistent and thus updated in all databases for each event. Further, only the data relevant for at least two departments should be exchanged or held centrally. Because of the different levels of confidentiality of the information, a differentiated rights management system must be available. Any developed solution should rely on existing standard software applications to keep expenses and implementation efforts as low as possible. On the other hand, it should be kept very flexible because of the various software systems and business structures of the diverse companies. Actually most of the companies are not set to store all relevant project data in external project spaces, e.g. for reasons of confidentiality or security. To avoid double storage of information, the data management systems should partially open themselves to the project space, to provide and get relevant information to or from the involved partners. Therefore the sharing of information within the project should be similar to the company internal model, but on another layer. Figure 1 shows this concept with the example of a company with 2 departments working on 1 project. Because of parallel planning steps, keeping the data unique, consistent and up-to-date is more complex. As a matter of fact, real-time updating is not possible with regard to the possible interferences between the project partners while planning.

Optimization of project processing in the steel

157

Figure 1. Data sharing model within company and within project 2.3 Document vs. data exchange The pure document exchange delivers only semantic contents to the concerned actor. He has to analyze the information and perform the necessary tasks emanating from this information. In most cases he will have to acquire this information in his own software. This causes time losses and increases possible sources of error with regard to data consistency over the whole project. Therefore data exchange is to favor over pure document exchange. The user of the software should become the checker of the model, while it is directly taken over by the software from the exchange file.

eWork and eBusisness in architecture, engineering and construction

158

2.4 Process automation Although most of the building projects are unique, there are some common processes. From the project view this could be the notification of changes to the concerned partners, from the company view a specific task, e.g. transfer of CAD-data to NC-production. An integrated project processing system should allow the definition of workflows and handle them at least partially. For example if the architect changes a geometrical information of the building, this information should be communicated automatically to the concerned project partners. The degree of automation obviously depends on the information format—in case of compatible data the latter change could be directly and automatically imported by the concerned program, which would require the authorization from the planner to save it. 3 SOFTWARETOOLS 3.1 Internet based project management systems Internet based project management (IBPM) systems provide a virtual project space for the involved partners. These internet platforms have 3 main functionalities. First they work as a central project server, where all documents are stored, and thus are available for further tasks, e.g. facility management. The whole project communication is performed over those platforms. Assumed that the project partners check it, this ensures a better information flow. Finally IBPM-systems allow the definition of workflows and thus a better control of the project process. The main problem remains that most of the companies will not source out all their documents and thus may hold them twice. Further the virtual project spaces do not allow the systematic exchange of data, but only of documents. 3.2 Peer-to-peer applications Opposite to virtual project spaces, peer-to-peer applications only interconnect the local computers of the partners over the internet, without any central data storage. The user of a peer-to-peer network can release documents or files in this network and make them accessible to other users while they remain on his own server. The major advantage is that no additional memory space is required on the internet-server, but each file may be stored in the system of each partner. Peer-to-peer networks are commonly used for private applications, but did not assert themselves yet for project processing in steel construction domain. The different principles of peer-to-peer networking and virtual workspaces on the internet is shown in Figure 2 by the example of partner A, who “adds” a new document to the project.

Optimization of project processing in the steel

159

Figure 2. Exchange principles of virtual project spaces and P2Pnetworks.

eWork and eBusisness in architecture, engineering and construction

160

3.3 Product models Product models intend to provide compatibility between a series of computer applications and thus allow the direct data exchange mentioned in 2.3. They consist of a neutral standard which defines all needed objects and is implemented in the applications. With regard to German steel construction domain, the Produktschnittstelle Stahlbau (DStV 2002) is to be mentioned. It is one of the few interfaces which is largely used in design practice and covers steel construction specific tasks from the raw design to the detailing over the structural analysis. In view to a global approach to the A/E/C domain, the Industry Foundation Classes (IAI 2002) is the most promising product model. Its purpose is to cover all domains of expertise, but the model is yet not ready to be applied on largescale in steel construction domain. Figure 3 shows the concept of product modeling by the example of the steel construction domain. 3.4 Object-oriented modeling The object-oriented modeling is the basis for very adaptive simulation due to its layered structure as shown in Figure 4. The objects are instances of

Figure 3. Product model as a link between the diverse proj ect partners of the steel construction domain.

Optimization of project processing in the steel

161

Figure 4. The layered structure in object-oriented programming. classes of the model. The meta-model defines those classes. In order to evaluate a knowledge model, its structure has to be analyzed (Firmenich 2004). This programming concept is also used for the development of product models, for which the classes of layer 1 are defined and implemented, and the diverse programs generate the instanced objects in exchange files. The re-use of an existing meta-model allows the compatible extension of an existing knowledge model. 4 INTEGRATED PROJECT PROCESSING 4.1 General approach The basic idea of the approach for an integrated project processing system is to define basic entities of a company or a project and link them. From there on processes can be modeled easily, e.g. if the entity “file” is changed, then inform all linked entities “project partner”. To keep the approach human-centered, a tool to model the company’s structure has to be defined first. Then the latter is connected with a project platform where all exchanges between the involved actors occur. The company internal entities must also be linked with the project platform entities. Because of the diversity of the fields of activity of the involved partners, the handled model of the platform has to remain simple and cannot represent all entities of all partners. 4.2 Adaptive company model To define any process and control it with any software, first of all the basic entities of a company or a project have to be defined. Later they will be linked together. This allows to assign any information in any format to an actor or a process etc. The project processing tool has to offer resources to define those entities, to link them. Further it should have a simple messaging tool, to allow at least very simple workflows, e.g.

eWork and eBusisness in architecture, engineering and construction

162

noticing new versions. The proposed main classes to represent a company with its business structure are listed below: 1 Structure: defines the companies subdivisions, e.g. departments and employees 2 Project: defines projects and their subclasses 3 Partner: defines the partner types of the company, e.g. customers or suppliers 4 Product: defines the diverse products or services of the company 5 Tool: names the hard- and software tools of the company 6 Document: defines document types. Hence, each entity in the company is handled and can be addressed by the project processing system. Some

Figure 5. Example of a simplified company model, instances and workflow. of the above listed classes and their subclasses already exist in the IFC2x2 Model (IAI 2002). Because of the potential of this product model, its scheme will be used as a basis for our system. If required classes are not available, they will be formulated in accordance to the IFC meta-model. Further the software should also allow the development of strictly company internal classes by the user, i.e. meta-model rules should also be implemented in the system. In this way the system allows exact images of

Optimization of project processing in the steel

163

the company’s structure. The pre-defined classes must be those which are required within the project environment. Once a company model is defined, the entities can be linked to each other. The management of those links has to be performed with this developed project processing tool. If those links are available, workflows can be easily defined in the system. Figure 5 shows the above introduced principles. Once the companies entities are defined in a neutral model, they can be instanced and linked. Those instances and links can be addressed by workflows. Assumed that the concerned application software has accessible database structures, also more complex workflows can be defined, like automatic updating. 4.3 The project platform To open the company to the project environment, its internal organization and process model has to be connected with a project platform. The latter should be used for project communication and document or file exchange. Because of the volume of accruing data and their diversity, the idea of one unique file containing and treating all information is not realistic. A better approach is to provide a simplified building model on the project platform, which represents basic subdivisions of a building (Petersen & Diaz 2004). Within the scope of this investigation, the building is split into basic elements of steel construction domain. Those construction entities are then linked with concerned project partners. With the company internal linking concept presented in 4.2, the latter step is sufficient. The entity in the project space is automatically linked with all concerned entities within the company. The information attached to the simplified model is unique and stored on the internet platform. The real documents are accessible by links to local servers. This also allows a better access control for the document’s owner. To guarantee data consistency, versions of detailed documents have to correspond to the version of the related coarse element on the platform. If more detailed data are connected to one coarse element, the more checks of consistency are necessary. On one hand this leads to an optimization problem of the simplified model’s accuracy. On the other hand this situation is a very strong argument for the use of product model based exchange files, where checks can be performed automatically in a relatively simple way due to the common file format, and the information can be directly taken over by the software. In a first step, the common standard for data exchange can be the Produktschnittstelle Stahlbau, because it is already used in the practice. But, because of its larger scope, the advantages of the IFC are evident in this case. Figure 6 shows the concept of the proposed project processing system with its internet platform and the peer-to-peer networks. In the example, the civil engineer performs a change on frame A. The notification processes run over the common internet platform. The internal links lead to the detailed data. Two alternatives are presented with regard to the updating of information in the detailed files. In one case, the concerned planner in the steel construction company gets to the changed file of the structural engineer over the peer-to-peer access and performs the modifications afterwards on his file. In the second case both file formats are compatible and a direct exchange can be performed.

eWork and eBusisness in architecture, engineering and construction

Figure 6. Proposed information flows of the project processing system.

164

Optimization of project processing in the steel

165

5 EVALUATION The above presented approach of a project process management system shall ensure data integrity within A/E/C companies and within their projects. The system shall dispose a simple messaging system. Assumed that the partners are considered by the company model, an easy and systematic notification of changes is possible. If the used standard software applications have open database structures, the update of data can be automated, since their information contents are also instanced by the mentioned model. Thus, the approach offers an immediate possibility to enhance data consistence by better communication between the concerned actors, and in a further step, automation of updating is possible. The adaptation of the method is up to the system administrator. With the use of a simplified model on the shared project platform, interdependencies between diverse project partners can be defined or detected easier. Further the data volume on the web-server is limited. The peer-to-peer approach for real file sharing allows a better access control within the company, which enhances the security and confidentiality. The concept of the presented system is based on the improvement of existing project communication systems. It does not depend on any product model standard, but only on the abilities of the already existing and applied software applications of the companies. Thus it offers a progressive approach of process optimization. Because of the use of existing standards, it can be developed and applied in practice relatively rapid. The first step is to provide a company modeling tool and a virtual project space. Then the process model can be extended steadily. The applicability to other domains is ensured by the general and adaptive approach of the project pro cessing system. But as the process automation potential is dependent on the scope of product models, its efficiency is also dependent on the latter. 6 CONCLUSION This investigation shows, that an answer to the requirements of the industry can be found by combination and small extension of existing technologies. In a first step, data consistency and communication within companies and within building projects can be improved. In a further step, several repeating processes can be automated, and thus the efficiency of the sector improved. The Lehrstuhl für Stahl- und Leichtmetallbau is developing a prototype system in cooperation with industry partners, which will be tested on real building projects. REFERENCES Deutscher Stahlbauverband (DStV) 2002. Standard-beschreibung Produktschnittstelle Stahlbau Teil 1, Teil 2, Teil 3 and Standard description for product interface steel construction. http://www.stahlbauverband.de/asp/biblioaussdet.asp?auss=7.

eWork and eBusisness in architecture, engineering and construction

166

Deutscher Stahlbauverband (DStV), Arbeitsausschuss Informationstechnologie, Ad-hoc Arbeitsgruppe Ablauforganisation 2004. Grundsätzliche Anforderungen an ein integriertes Management- und Informationsystem für kleine und mittlere (Stahl-) Baufirmen. Not published. Firmenich, B. 2004. Product Models in Network Based Cooperation in Structural Engineering. Karl Beucke et al. (eds), Proceedings of the Xth International Conference on Computing in Civil and Building Engineering, Weimar, 02–04 June 2004. International Alliance for Interoperability (2002). IFC 2x2 Final Documentation. http://www.iaiev.de/spezifikation/Ifc2x2/index.htm. Katranuschkov, P., Sherer, R.J & Turk, Z. 2002. Multi-project, multi-user, multi-integration: the IST for CE integration approach. In Ziga Turk & Raimar Scherer (eds), ECPPM 2002, eWork and eBusiness in Architecture, Engineering and Construction; Proc. intern.. conf., Portoroz, 9– 11 September 2002. Petersen, M. & Diaz, J. 2004. Integrated Planning of Buildings based on Computer Models in Project Communication Systems. Karl Beucke et al. (eds), Proceedings of the Xth International Conference on Computing in Civil and Building Engineering, Weimar, 02–04 June 2004.

eWork and eBusiness in Architecture, Engineering and Construction—Dlkbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Location sensing for self-updating building models O.Icoglu & A.Mahdavi Department of Building Physics and Building Ecology, Vienna University of Technology, Vienna, Austria ABSTRACT: Emerging technologies in building automation have the potential to increase the quality and cost effectiveness of services in the building industry. However, insufficient range of collected data and models of the physical and behavioral aspects of the facilities limit the capabilities of building automation systems. We describe a project for improving building services by collecting comprehensive data from variable sources and generating high-resolution models of buildings. In this context, location sensing is critical not only for data collection, but also for constructing models of buildings as dynamic environments. We first examine a range of existing location sensing technologies from the building automation perspective. We then outline the implementation of a specific location sensing system together with respective test results.

1 INTRODUCTION Building automation is expected to improve building performance by reducing the operation and maintenance costs of buildings (e.g. for heating, cooling, and lighting), improving environmental performance, augmenting human comfort, and providing higher safety levels. However, data collection and monitoring activities in current building automation systems are rather limited: the focus is mostly on service systems such as elevators and office equipment. There is a lack of systematic and scalable approaches to comprehensive facility state monitoring throughout buildings’ life cycle. To achieve a higher level of building automation technology, collected data must cover not only the state of systems such as elevators, but also the state of room enclosure surfaces, furniture, doors, operable windows, and other static or dynamically changing building entities. Toward this end, we focus on generating comprehensive and self-updating models of the physical and behavioral aspects of facilities over their life cycle (Mahdavi 2001a, 2001b, 2003, Mahdavi & Suter 2002). Thereby, we are developing and implementing a prototype sensor-supported self-updating building model for simulation-based building operation support (Mahdavi 200Ib). To deliver a proof of concept for the feasibility of the system, we focus on lighting controls in a test space. The control scenario is as follows: at regular time intervals, an Executive Control Unit (ECU) considers possible changes in the states of control devices (e.g. the dimming positions of the electrical light fixtures, the position of window shades). The ECU then requests a lighting simulation program to predict the implications

eWork and eBusisness in architecture, engineering and construction

168

of device states for the lighting performance of the space (i.e. light availability and distribution) in the immediate future time interval. Based on the comparison of the predicted performance levels with desired (user-based) objective functions, the ECU initiates the transition to the most desirable control state. For this scenario to work, the underlying model generation system must consider a wide range of space and system characteristics, including the spatial and material properties of a space as well as the state of the luminaries and furniture. Specifically, the lighting simulator requires an accurate and up-to-date model of both internal space and external conditions (i.e. the sky luminance pattern) to run the necessary simulations. This implies the need for a location sensing system to provide real-time identification and location data for the construction of a space model. This information is subsequently used by the ECU to construct a 3D object model in the system database. The resulting model can be used for lighting simulations. Similar models can be constructed to inform other applications for building operation and facility management support. The challenge in constructing a model is that the building infrastructure is not a static entity and may change in multiple ways during its life cycle. In office buildings, an indicator for these dynamics is churn, that is, the number of office moves during a given year. Depending on the flexibility of a building’s systems, churn can involve significant infrastructure changes. According to one study on churn, freestanding furniture changes daily to monthly, or modular partitions once a year (Ryburg 1996). The ability to track such changes automatically is necessary for the viability of simulation-based building control. In our prototype, this task is performed by a location sensing system. 2 LOCATION SENSING TECHNOLOGY REVIEW Prior to the implementation of a location sensing system, the available technologies are examined from the building automation perspective (Brunner et al. 2004). A suitable system must be capable to identify individual objects and return their locations. Furthermore, it should require minimum maintenance, and be scalable to adapt itself to changes in a facility. In addition to these basic requirements, accuracy, unobtrusiveness (minimal installation and maintenance necessary), cost, scalability, and identification capability are also considered among the primary evaluation criteria. Most currently available location systems use tags, small items affixed to the actual objects to be tracked. Location information is obtained by signal exchange between these tags and a sensor infrastructure (sensors, readers). Even more so than in other ubicomp applications, building model applications call for rather small, long-lived tags that require no batteries or any other maintenance. Moreover, systems based on devices that obtain or calculate position information internally (called localized location computation) are not meaningful in building model applications, unless the location information is fed back to the overall system. Among the available technologies, the ones that exploit electromagnetic and radio frequency, ultra-sound, and optical/vision-based methods are specially noteworthy. Electromagnetic and radio frequency include technologies based on the measurement of electromagnetic or radio frequency signals’ field strengths, distortion, time-of-flight or frequency. Ultrasound-based systems typically consist of battery-powered tags and a set

Location sensing for self-updating

169

of transponder stations communicating with them; position information is obtained by measuring time-of-flight of acoustic signals. Vision-based technologies utilize visual attributes of the objects or the tags attached to them and use computer vision methods to extract the identification and location data. Based on this technical review (Brunner et al. 2004), it is concluded that there is no perfect location system for self-updating building models today Vision based methods appear as the most appropriate solutions that can form a basic infrastructure to our requirements because of being software-supported and open for modifications and improvements. The latest developments in distributed programming, software agents and high power processors also make the vision-based solutions more promising. Based on this technical review, we have adopted such a system, as described in the following sections. 3 LOCATION SENSING SYSTEM FOR SELF-UPDATING BUILDING MODELS 3.1 System framework Our system is designed as a vision-based location sensing that uses a combination of visual markers (tags) and video cameras. Among the reviewed vision-based methods, the algorithm proposed in TRIP (Lopez 2002, Lopez et al. 2002) offers a suitable solution for location sensing in building environments. The TRIP algorithm uses optimized image processing and computer vision methods, and benefits from low-cost, black-and-white tags. It obtains in real-time the identification and location (both position and orientation data) of an object to which the visual tag is attached. Our assessment criteria (see section 2) emphasize that the location system should also provide fine-grained spatial information at a high update rate while being unobtrusive and scalable in terms of sensing the locations of many objects in a wide area. To meet these requirements, our Location Sensing System (LSS) is designed in a distributed structure, with the software components tied together by the Internet. Communication and data sharing is ruled by the Distributed Component Object Model (DCOM) protocol that enables these software components to communicate over a network (DCOM 2004). The distributed structure of the LSS enables scalability and incremental growth, in addition to enhanced performance derived from parallel operation. Figure 1 shows the framework of the LSS. It comprises four main software components: Application Server, Database Server, User Interface Server, and Target Recognition and Image Processing (TRIP) Clients. The Application Server is the central unit that controls the distributed components of the system, and performs resource sharing and load balancing among the clients. Resources are the available computing and sensor devices in the system. The Network cameras (NetCam) are used as sensors that own dedicated IP addresses, and act like network devices. TRIP Clients are the consumers of sensor and computing resources that run these client programs. A TRIP Client acquires images from the network cameras and applies image processing to extract the identification and location of the tagged objects. TRIP Client programs are implemented on different computers (computing resources) that may

eWork and eBusisness in architecture, engineering and construction

170

be distributed across a facility, and their number can be increased as needed. The results obtained from multiple clients are combined in the Application Server, which is also responsible for controlling the status of the cameras and TRIP Clients. It informs the operator (a facility manager, for example) of inactive sources and dynamically assigns active cameras to active TRIP Clients by taking their workload feedback into consideration. This arrangement minimizes operator overhead.

Figure 1. Structure of the LSS. All data regarding TRIP Clients, cameras, object information and system parameters are stored in the XML (Extensible Mark-up Language) format. The Database Server provides remote access to XML data for other components of the LSS. The User Interface Server is responsible for the communication between an operator and the system. It is a web based CGI (Common Gateway Interface) program that can be accessed from any computer on the network. It presents combined location sensing results (object identifications and locations) to the operator and enables the adjustment of system parameters from web browsers. 3.2 Processing steps in the LSS The primary goal of the LSS is to collect visual data from the sensors, and extract object identification and location information in a wide area. Figure 2 demonstrates the process flow that takes place in the system to convert images to location data. Raw camera data is acquired and subsequently transferred to the Image Processing unit through the Camera

Location sensing for self-updating

171

Interface. Object IDs and locations are extracted by the Image Processing unit and are conveyed subsequently to the Coordinate Translation. Coordinate Translation transforms the location data with respect to camera coordinates to the location data with respect to room coordinates. Multiple Image Processing and Coordinate Translation units run parallel in the LSS, as they are implemented within distributed TRIP Clients. The ID and location data extracted from various camera devices are combined in the Object Fusion phase utilizing current and previous object information. Final results are transformed into data packets for convenient data communication, and transferred to the main system, ECU, for model construction. These data are also transferred to the Object History database for the further processing of the Object Fusion.

Figure 2. Process flow in the LSS.

eWork and eBusisness in architecture, engineering and construction

172

3.2.1 Camera Interface Network cameras are used as sensor devices for capturing images of the environment, where eachNetwork camera owns a dedicated IP address, and acts like a network device. Network cameras are inexpensive, off-the shelf products. They have web servers embedded inside that convey images to the consumers in wide areas through HTTP. Camera Interface is executed in the TRIP Clients for each network camera assigned by the Application Server. This unit acts like a hardware interface and isolates the software parts of the system from the hardware units. Thus, the effect of any change of the hardware to the overall system is minimized. Camera Interface performs the communication and image acquisition with establishing a connection to the network camera as a web client, where the required communication parameters are retrieved from the Camera Database (Fig. 2).

Figure 3. Sample visual tag with TRIP code: 10 2011 221210001 (evenparity=10, radius length=58 mm, ID=18795) (Lopez et al. 2002). 3.2.2 Image Processing Image Processing, executed within the TRIP Client component, acquires images from the Camera Interface and applies image processing algorithms for location sensing (Fig. 2). The system works with circular black-and-white TRIP coded tags that can be gener- ated with an ordinary laser printer (Fig. 3). Patterns on the circular partitions of the tag determine the position of synchronization sector (starting point, 1 partition), even-parity bits (2 partitions), actual length of the radius of the tag in millimeters (4 partitions) and ID code (9 partitions). The Image Processing unit enhances the original TRIP system (Lopez 2002, Lopez et al. 2002) by integrating two additional algorithms that make it suitable for the building environments. The original system was implemented on images captured by digital cameras that provide uncompressed, high quality data. However, in the real world, working on raw images is not applicable in distributed environments such as buildings.

Location sensing for self-updating

173

Network cameras, like other digital video devices, are designed to convey images as fast as possible for user convenience and therefore apply compression on the original images prior to transmission. To overcome the compression artifacts, enhancement algorithms are integrated as described in the following. 3.2.2.1 Original Image Processing method The original method comprises “target recognition” and “pose extraction” algorithms that turn the input images of tags into location and identification data. The “target recognition” algorithm determines the identification and geometric properties of the projections of TRIP tags. Since the projection of a circle in an image generates an ellipse, TRIP tags’ circular patterns are observed as elliptical, and parameters of these ellipses are extracted from the image. The outermost ellipse of a detected tag is marked as “reference ellipse” and its parameters are used for the pixel sampling procedure of TRIP code deciphering. The intensity values of the pixels at point locations around the reference ellipse determine the entire TRIP code. The TRIP code is finally validated with the evenparity check bits (Lopez 2002). “Target recognition” returns the ID number, radius of the tag, the position of synchronization sector and the parameters of the reference ellipse for each identified TRIP tag. The “pose extraction” algorithm takes these values as input in order to determine the 3D position and orientation of TRIP tags with respect to the camera. The algorithm implements a transformation that back-projects the elliptical border of a tag lying on the camera image plane into its actual circular form lying on the centre of the target plane. The reverse projection makes the camera image plane become parallel to the target plane and retrieves the 2D orientation of the TRIP tag by giving out the angles around the camera’s axes X and Y, α and β respectively. The position of the synchronization sector is used to extract the final component of the orientation, angle around Z-axis, γ. The distance between the camera and the target plane, d, is computed using the radius length of the tag. Thus, in addition to orientation, position vector [Px, Py, d]T is also generated where Px and Py are computed from the central point of the reference ellipse. 3.2.2.2 Enhanced Image Processing method In our application, network cameras apply wavelet transformation with a 10:1 compression ratio. This process generates smoothed input images for the TRIP Clients and causes the tag images to lose sharpness. To compensate this, TRIP Clients apply an “adaptive sharpening algorithm” (Battiato et al. 2003) on the input image prior to target recognition (Fig. 4). This method restores first the original image by an un-sharp masking process, which is naturally affected by noise and compression-based ringing artifacts. The algorithm then minimizes these artifacts by combining the adaptively restored image with the original. In addition to camera artifacts, an increase in the distance of tags to camera reduces the pixel resolution of the tag images and makes the TRIP codes harder to decipher, even though the tags are detected and reference ellipses are extracted properly. To solve the problem, “edge-adaptive zooming” (Battiato et al. 2000) is applied locally to spurious

eWork and eBusisness in architecture, engineering and construction

174

TRIP tags from which the TRIP code could not be deciphered or validated. “Edgeadaptive zooming”, as opposed to its counter-parts such as bilinear and cubic interpolation, enhances the discontinuities and sharp luminance variations in the tag images. This procedure is repeated until the “target recognition” succeeds or the zoomed image region loses its Details (Fig. 4). The latter case indicates a false alarm or an unidentified tag. 3.2.3 Coordinate Translation and Object Fusion Coordinate Translation is executed within TRIP Clients after Image Processing (Fig. 2). The outcomes of Image Processing are a position vector and orientation angles

Figure 4. Enhanced image processing algorithms. with respect to camera coordinates from which the processed image is acquired. Coordinate Translation converts these to the location data with respect to room coordinates. The location of each camera with respect to the room coordinate system is stored in the Camera Database. This location data involves the coordinate-rotation vector [Rα, Rβ, Rγ]T, that overlaps the axes of the coordinate systems, thus, when combined with the original rotations (α, β, γ), gives out the orientation values with respect to the room. The location data also involves the coordinate-translation vector [Tx, Ty, Tz]T, that aligns the origin of the camera coordinate system to the origin of the room coordinate system, and

Location sensing for self-updating

175

eventually gives out the position vector with respect to the room when combined with the original position vector, [Px, Py, d]T. Object Fusion, implemented in the Application Server, combines the object identification and location data acquired from parallel-running TRIP Clients (Fig. 2). The same object may be detected with multiple cameras, each of which is assigned to different TRIP Clients. This may generate repeated records in the system. Object Fusion combines these reiterated data based on identification codes and room coordinate locations. Furthermore, TRIP Clients attach time stamps on each extracted object’s location data. In cases of inconsistency, Object Fusion uses previous object data to perceive the correct identification or location information, and generates the final, unique object information. 4 A DEMONSTRATIVE TEST To evaluate the performance of the LSS, a demonstrative test was performed to observe the identification and location accuracy. The test configuration was

Table 1. Percentage of identified tags as a function of distance and angle for the “original” and “enhanced” methods. Angle

Distance

Original

Enhanced

0°

2m

100

93

78

100

97

90

30°

3m

82

78

53

97

90

84

60°

4m

42

36

18

81

78

56

designed to address system limitations. One limitation is the “distance” of the tags from the camera. An increase in distance reduces the resolution of the tags that makes pixel sampling unable to locate the circular regions within the tag image. A second limitation is the “incidence angle” between the normals of the target plane and the image plane. As the incidence angle increases, the elliptical properties of the tag image projections become more difficult to acquire. In our test, 16×16 cm tags were located at 3 different distance values (2, 3, 4 m) and, for each distance, 3 different incidence angles were evaluated (0°, 30°, 60°). Thirty sequential readings for each location were recorded using the TRJP Client program and a network camera with 1/3′ CCD sensor and 720×486 resolution. As camera artifacts affect input images in changing magnitudes and spatial values, multiple samples were taken for each designated location. The test was performed with the “original” and “enhanced” Image Processing methods as described above. Identification percentages are given from the sequential reading results in Table 1. In addition to identification, location results were also observed. For the enhanced method, the position and orientation data are within a maximum error range of ±10cm

eWork and eBusisness in architecture, engineering and construction

176

and ±10 degrees for 3 m distance. The error rates show an increase to ±20 cm and ±35 degrees for objects located within 3 to 4 m distance. A single TRIP Client program running on a 2 GHz processor possesses an average update speed of 5 image frames per second. The update speed of the overall system is dependent on the number of cameras and TRIP Clients employed and it is configurable based on the facility requirements and budget. Increasing the number of cameras also increases the amount of space being covered by the LSS. However, this eventually increases the image production rate and reduces the overall update speed. The resulting drawback can be compensated with adding new TRIP Clients. Multiple TRIP Clients executed in the system share the workload and may increase the update speed per camera up to its maximum frame transfer rate. 5 CONCLUSION AND FUTURE DIRECTIONS We have presented a location sensing system to support self-updating building models for building automation applications. The implemented system has some drawbacks inherited from the general disadvantages of the visual methods as it requires line-of-sight between the camera and tags, and its performance is dependent on the cameras’ image quality. However, the results obtained from our location sensing system suggest that vision based location sensing, when enhanced with software methods and integrated with appropriate hardware, is a promising technology suitable for spatial domains such as facilities and buildings. The implemented sensing system is still open for improvements. We expect that in the future the tag size can be reduced and the effective distance of the system can be augmented. Integrating pan/tilt units that can feed their position data back to the system will also increase the effectiveness of the cameras. In addition, currently, coordinate translation data has to be updated for any displacement of the cameras. Utilizing reference tags will facilitate the automatic calculation of coordinate translation data, allowing the relocation of cameras without manual system reconfiguration. ACKNOWLEDGEMENT The research presented in this paper is supported by a grant from FWF (Austrian Science Foundation), project number P15998-N07. The research team includes, in addition to the authors, G.Suter, K.Brunner, B.Spasojevic, L.Lambeva, and M.Mohamadi. REFERENCES Battiato, S., Castorina, A., Guarnera, M. & Vivirito, P. 2003. An adaptive global enhancement pipeline for low cost imaging sensors. IEEE International conference on consumer electronics, Los Angeles, June 2003. 398–399. Battiato, S., Gallo, G. & Stanco, F. 2000. A new edgeadaptive algorithm for zooming of digital images. IASTED Signal Processing and Communications, Marbella, September 2000. 144–149.

Location sensing for self-updating

177

Brunner, K., Icoglu, O., Mahdavi, A. & Suter, G. 2004. Location-sensing technologies for selfupdating building models. (to be published). DCOM. 2004. Microsoft COM technologies—Information and resources for the Component Object Model-based technologies. http://\vww.microsoft.com/com/ Lopez de Ipina, D. 2002. Visual sensing and middleware support for sentient computing. PhD dissertation, University of Cambridge, 2002. Lopez de Ipina, D., Mendonca, P.S. & Hopper, A. 2002. Visual sensing and middleware support for sentient computing. Personal and Ubiquitous Computing. 6(3): 206–219. Mahdavi, A. 2001a. Aspects of self-aware buildings. International Journal of Design Sciences and Technology. Paris. 9(1):35–52. Mahdavi, A. 2001b. Simulation-based control of building systems operation. Building and Environment. 36(6): 789–796. Mahdavi, A. 2003. Computational building models: Theme and four variations (Keynote). Augenbroe, G./Hensen, J. (eds). Proceedings of the Eight International IBPSA Conference, Eindhoven, 2003. 1:3–18. Mahdavi, A. & Suter, G. 2002. Sensorgestützte Modelle für verbesserte Gebaeudeservices. FWF proposal, 2002. Ryburg, J. 1996. New churn rates: people, walls, and furniture in restructuring companies. Facility Performance Group, Inc. 1996.

eWork and eBusiness in Architecture, Engineering and Construction—Dlkbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Modeling cast in place concrete construction alternatives with 4D CAD R.P.M.Jongeling, T.Olofsson & M.Emborg* eBygg—Centre for Information Technology in Construction, Luleå University of Technology, Luleå, Sweden *Betongindustri AB— Heidelberg Cement Group, Stockholm, Sweden ABSTRACT: This paper presents the results from a 4D modeling study in which 4D CAD was used to compare two different construction methods for a cast in place concrete structure. Evaluating construction alternatives in a virtual environment is considered to be an effective and cost efficient way to introduce and evaluate innovative construction processes and products. Results from the study show the potential of using multiple virtual prototypes, but also show limitations regarding required modeling effort and evaluation of results. Improvements are suggested that facilitate and partly automate the 4D modeling process. Evaluation of the outcome of 4D models can be improved by extending the graphical outcome of the modeling process with a variety of analyses. Research and development is needed to quantify results from 4D models, in order to allow comparison of construction alternatives on a range of different criteria.

1 INTRODUCTION The planning process in the construction industry is focused on organizations and work breakdown instead of construction operations, flows and supply chain management (Ballard 2001). Decision-making is often based on practice, general information and assumptions, resulting in sub-optimal solutions that often have a negative impact on the total project costs. Product and process innovations are not easily adapted in this practice. A widely used method for process modeling is the Critical Path Method (CPM). The method concentrates mainly on the temporal aspect of construction planning and is seen as one-dimensional (Heesom 2004). Construction projects have unique spatial configurations and the spatial nature of projects is very important for planning decisions (Akbas 2004). CPM schedules do not provide any information pertaining to the spatial context of project components and requires users to look at 2D drawings to conceptually associate components with the related activities (Koo 2000, 2003). This approach limits evaluation and comparison of alternative solutions. 4D modeling is a new process method in which 3D CAD models are visualized in a 4dimensional environment. Construction plans can be represented graphically by adding the time dimension to the 3D model to allow project planners to simulate and analyze what-if scenarios before commencing work exe cution on site (Mallasi 2002). Koo (2000) identifies 4D modeling as a tool to convey planning information (visualization tool),

Modeling cast in place concrete construction

179

enhance collaboration among project participants (integration tool), and to support users to conduct additional analyses (analysis tool). Although geometrical data and temporal data are present in commercial 4D CAD software, the utilization of these models has so far mainly concentrated on the visualization of construction processes, rather than on integration and analyses of construction operations. However, recent research efforts in 4D modeling show an increasing interest in providing an integrated 4D environment to support a variety of analysis of for example work spaces, work flows and use of resources (Akbas 2004, Akinci 2002, Heesom 2003, Li 2003, Mallasi 2002). In this paper we describe the relevance of 4D modeling as an instrument to introduce construction innovations and to evaluate construction alternatives. We report the implementation and findings from a 4D modeling project conducted by a Swedish ready mixed concrete supplier, in which 4D was used as a tool for visualization and integration. The use of an Internet-based collaborative engineering environment to support interactive decision-making processes is introduced, which was used to create 4D models. The main findings and results from the study provide a base for fiiture research aimed at defining methods for 4D comparative analyses of construction alternatives. 2 MARKETING CAST IN PLACE CONCRETE 4D modeling formed the basis for a marketing project conducted by a Swedish ready mixed concrete supplier. Motivation to conduct this project followed from routine problems in the supplier’s business process. The supplier’s marketing department experienced difficulties in introducing new products and production processes to its clients: project developers and contractors. As an example the introduction of permanent form work systems can be given. Paperbased brochure material and 2D engineering drawings are commonly used to communicate product characteristics. The process of applying these products on site is communicated via spread sheets and CPM schedules. These media and tools are considered to be insufficient to create a common understanding in project teams about advantages and disadvantages of new products and production technologies. An alternative approach for introducing new innovations is performing a full scale study in a pilot project. However, such projects are often expensive and resource intensive. Furthermore, there is a risk that the efficiency and effectiveness of innovations are not clearly shown, caused by a lack of experience, and other parameters such as weather conditions that are beyond control of the project organization (Jongeling 2004). In an effort to adequately support the introduction and evaluation of construction innovations a pilot study was initiated in which 4D simulations were made to evaluate two construction alternatives of a residential construction project. – The first alternative, the 0-Reference scenario, represented today’s common practice for cast in place concrete construction. The objective of this scenario was to represent typical sequenced and concurrent activities on a construction site that are related to casting of concrete walls and slabs. – The second alternative provided an industrialized approach to cast in place concrete construction. A number of innovative production technologies formed the basis for

eWork and eBusisness in architecture, engineering and construction

180

this alternative. The objective was to visualize the potential for permanent form work systems in combination with the use of prefabricated carpets of reinforcement and self compacting concrete. Such a combination of innovative production technologies had not been applied in actual projects and the possibility to evaluate these methods in a virtual environment was considered to be very useful. The simulations, by realistically visualizing typical construction activities, provided a foundation and a base for evaluating the differences between traditional and permanent form work systems. The period of construction was used as a primary comparator. Typical construction activities were defined as operations needed for the installation of form work, reinforcement and concrete. Original 2D architectural drawings from a typical residential construction project were used to create a two-storey 3D CAD model. The 4D experiments were conducted after the actual construction of the project was finished and have no direct relation to the construction process by the contractor. Modeled scenarios were based on estimates of product and process data acquired from experienced practitioners at the supplier and other actors in the Swedish construction industry. Many hypotheses and limitations were made in planning and representing these processes in a 4D CAD environment. For example, the planning of resource use was not directly addressed in this study. 3 MODELING ENVIRONMENT A main interest in the study was to investigate the possible and practical use of the software tools and 4D simulations in practice. For this reason software tools were selected that were to some degree already familiar to both the supplier and other project participants. The 3D models were created by using AutoCAD Architectural Desktop (ADT) as client software to an Internet-based database management system, developed by Enterprixe Ltd (Enterprixe 2002). The system stores all project data in a central database, to which project members have concurrent access over the Internet. Depending on access rights, users can view or edit information by loading data from the server to local software clients. The server keeps track of the modeling work and modifications by connected users, who can check out and check in parts of the project. The contact between the concrete supplier and its clients is often highly interactive and intense during certain stages of a construction project. The interoperability environment provided by the modeling system was therefore considered useful to support these processes and to ensure consistency of data. The possibility to create a user defined object hierarchy for 3D CAD objects was another reason to apply the modeling system. This functionality facilitates the creation of multiple parallel CAD object hierarchies that can represent different construction alternatives. 4 MODEL COMPONENTS The following section describes the method and findings of the modeling work of the main 4D model components for both construction alternatives.

Modeling cast in place concrete construction

181

Figure 1. Main object hierarchy in AutoCAD Architectural Desktop, used as client software to the Enterprixe model server. The project database contained four CAD object groups per construction alternative: – Building Model; – Casting Sequences; – Form Work; and – Reinforcement. In addition, the project database contained imported CPM schedule information for both construction alternatives. 4.1 Building and production model The building model served as a base for the project and included the geometry of building components. This model was based on architectural 2D drawings and was the same for both alternatives. A production CAD model, based on the building model, was created consisting of form work elements, reinforcement bars and casting sequences for the concreting work, Figure 1. The objects in the 3D CAD production model were linked to activities and work packages whereas the building model objects only were created to represent the geometry of the building. For this reason many objects from the building

eWork and eBusisness in architecture, engineering and construction

182

model had to be split and regrouped in order to suit the object hierarchy of the production model. 4.2 Schedule CPM schedules were created on two levels of detail in MS Project. The first level, the master level, contained the main work processes of the project. The level of detail in the master schedule was appropriate in conveying the overall daily work flow in the project, but was too abstract to represent construction operations on site. For example, activities such as installing and dismantling form work were not included in this schedule. The master schedule was subsequently detailed into a second level of detail in order to represent work flows more accurately. This level of detail included time frames of 10 minutes and led to CPM schedules with large number of activities for the various work flows. For example, the activity “cast concrete walls phase one” from the master schedule was broken down into sub-activities; install traditional form work side A, install reinforcement bars, install traditional form work side B and cast concrete. These subactivities were further detailed to standard sections of form work and sections of reinforcement and walls. A similar approach was applied to the detailing construction operations for the slabs. The final CPM sChedule for both construction alternatives contained over 1500 activities. The CPM schedule was imported to the project database and manually linked to the respective objects and objectgroups. Color settings for the visualization of activities were made after the linking of activities to the 3D CAD models was completed. The order of installment of all 3D CAD components was determined in the CPM environment without a direct relation or visual check in the 3D model. Interdependencies between different work flows, i.e. form work, reinforcement and concreting, could only be checked after the CPM schedule was linked to the 3D CAD models. By browsing the time planning of the two models errors could be detected, such as work space conflicts and erroneous work flow directions. These observations led to updates in both the 3D CAD model and the CPM schedule that in many cases had to be restructured and relinked in order to work properly. Schedule changes were difficult to manage due to the large number of activities and the large number of dependencies between different activities. The process of linking and updating the CPM schedule and the 3D CAD model was labor intensive. 4.3 Casting sequences To define casting sequences for concreting work the building model was split in a number of work packages. Each of these work packages represented the concrete casting work for one day and included sections of walls and slabs. The sequences were planned in a traditional 2D paper-based way as this was deemed more flexible than planning the sequences in a 4D environment. Sequences for the casting process of walls were planned by using colored lines drawn into 2D drawings; each line representing casting work for one day. The length and distribution of lines were manually determined in five iterations in which a set of decision criteria was used. Main criteria were: required form work,

Modeling cast in place concrete construction

183

volume of concrete, work flow direction and possible work space conflicts. These criteria were considered implicitly and were not quantified in the decision-making process. In many cases the 3D building model components had to be split in a number of subcomponents, i.e. production objects, to represent the appropriate size of the individual concreting activities. This was a complex process as the planning for casting work kept changing during the modeling work. 4.4 Form work Form work was different for both alteraatives. The 0-Reference alternative was based on the use of traditional temporary form work. Traditional form work elements in the model purely had a visual purpose and were abstract representations of the actual form work elements. Form elements were grouped in the 3D CAD model by sections of standard length of elements. Modeling and grouping form work into work packages was a labor intensive process. Casting sequences determined the size and distribution of work packages in the 4D model. As noted in the previous section, the planning for casting work kept changing and subsequently the work packages containing 3D CAD form work elements had to be changed to keep the model consistent. A permanent form work system was used for the industrialized alternative. This form work consists of cement-bonded particle boards, which remain in the building after construction. As opposed to the 0-Reference alternative, where casting sequences determined form work activities; the permanent form work objects determined the planning for the industrialized construction alternative. 2D drawings were sent to a supplier of permanent form work systems, who manually planned wall and slab form elements in the drawings. Geometric data was manually extracted from drawings and used in spread sheets to calculate required resources and element costs. Hand-written element ID-numbers on 2D drawings were the key in linking 2D drawings and spread sheets together. All the form work elements for walls and slabs were modeled and organized in the 3D CAD model according to element ID-numbers given in the 2D drawings. For every form work element an activity was created in the CPM schedule that was linked to the corresponding 3D CAD element in the database. For the two storey building used in the project this implied 180 form work element activities for slabs and 170 activities for wall elements. The order of work for installation of form work elements did not follow the ID-numbers and was made in the CPM schedule by changing order of activities. Changing order of activities for form work often had an impact on approximately 70 shoring activities, 60 reinforcement activities and 80 concreting activities. This constrained the rapid evaluation of different work flow directions. It took approximately 15 iterations before an installment order was found that visually satisfied the planning criteria for work spaces and work space conflicts. 4.5 Reinforcement Dimensions, locations, and number of reinforcement bars were determined by visual analyses of the 3D CAD model. The reinforcement bars served a visual purpose and were

eWork and eBusisness in architecture, engineering and construction

184

not modeled for reasons of structural analyses. Reinforcement bars for slabs were distributed over equal distances and modeled in one direction in order to minimize 3D modeling work. The purpose of these bars was to show the reinforcement activity work zones rather than the actual reinforcement components. Planning the installation of reinforcement bars was done with the assumption of a constant production rate, i.e. every reinforcement bar would take the same amount of time. Specific geometrical situations were not taken into account. The relation between the geometry of reinforcement bars and productivity for installment could only be made visually. Considering specific production rates by analyzing the 3D and 4D CAD model in detail was beyond the scope of the project, but could have contributed to the accuracy of the simulations. 5 COMPARISON IN 4D Both construction alternatives were simulated in parallel in a 4D CAD environment, Figure 2. The two construction simulations showed to some extent similar work flows. Activities for form work, reinforcement, and concrete were carried out concurrently, enabling and constraining the execution of other activities.

Figure 2. Parallel simulation of construction alternatives in 4D CAD. (Left) 0-Reference alternative. (Right) Industrialized alternative.

Modeling cast in place concrete construction

185

The main differences between both alternatives were the dependencies between the different work flows and the production rate. This observation could be made visually, but was not supported by measured data from the 4D model. Parallel visualization was considered very effective to visually explain the differences between the two construction alternatives. The simulations were used in seminars in which a variety of professionals in construction was invited. It was generally agreed that the 4D models helped to understand the different construction processes, but it was noted that the models were limited in scope and non-interactive. Evaluation of alternative work flow strategies or changes in productivity could not easily be managed in the 4D model. The 3D CAD objects in the production model that had been created and grouped to represent specific activities, i.e. form work, reinforcement and concreting, constrained the rapid evaluation of alternatives. Changes in schedule implied often major changes in the production model, involving considerable remodeling work. The 4D models provided the actors from different disciplines an integrated visual impression of the construction alternatives, but there was a general need to support this visual analysis with data. We distinguish two types of actors here: specialists and managers. Specialists from different disciplines were mainly interested in making specific data analysis of the 4D models. In addition to the visual comparison in 4D, these actors were interested in making data analyses by using a range of criteria. Examples of these criteria are: changes in crew composition, distances between parallel work flows, amount of equipment, crews, available work spaces, etc. Data needed to make this analysis could not easily be extracted from the available 4D models. This was partly due to absence of specific input data and partly due to the fact that output data, i.e. the 4D model, was limited to mainly graphical information. Managers considered 4D models on a different level and considered Key Performance Indicators of both alternatives. These indicators would summarize findings from the various analyses by specialists in graphs that would provide them with a general impression of the performance of different alternatives. Some of the indicators that were suggested were rather specific, such as costs, resource use and project phase duration; others were more abstract such as the efficiency of work space use. Data to support these analyses could partly be obtained from the CPM schedule, but most of the needed data was not readily available. In summary, 4D models were considered very useful to visually compare construction alternatives, but limited in the sense that it was difficult to interact with the models. Next to the graphical output of 4D models, there was a need to quantiiy the results from the analyses to allow comparison of construction alternatives on different criteria. 6 DISCUSSION In this section we summarize the main findings from the conducted 4D modeling experiments. We also suggest a number of directions for future research and development.

eWork and eBusisness in architecture, engineering and construction

186

6.1 Building model and production model The pilot study started by using an architectural model as a base model. This model was too abstract to be used for representation of specific construction operations. In order to create a production model from the architectural model: – Changes were made in the 3D CAD object hierarchy. 3D CAD objects were regrouped to represented work packages and activities; – Certain objects had to be split and regrouped. This especially applied to large CAD objects, such as slabs; and – 3D CAD objects were added that were not present in the architectural model. As an example traditional form work can be given. The objects solely served a visual purpose and were abstract representations of actual form work elements. The detailed production model required considerable modeling effort and was due to its complexity and interdependencies rather difficult to manage. The complexity of the CPM schedule that contained a large number of dependencies between activities further constrained the management of the production model. Akbas (2004) notes that when models accurately represent construction operations, the model complexity increases significantly and consequently the effort required to create and maintain these process models. We consider two potential directions to address the issues related to creation and maintenance of production models: a geometry-based process model (GPM) and generation of CAD objects by feature-based 4D models. 6.1.1 Geometry-based process model Akbas (2004) suggests a process model based on geometric techniques. The use of geometry in this approach is not limited to visualization, but is integrally used to model and simulate processes. This approach seeks to simplify process modeling work. 4D input models are decomposed into sub-systems. The 4D input models are based on macro level CPM schedules. Every sub-system contains crew parameters, geometric work locations and interactions. The

Figure 3. Geometry-based process model. A triangular mesh is used to plan and visualize work flows and

Modeling cast in place concrete construction

187

work locations related to specific parts of 3D CAD objects. Differences in color in combination with arrows are used to indicate work flow directions. approach then reduces this process model into queuing networks and uses discrete event simulation to simulate construction operations. Each of these steps uses geometric techniques, such as triangle meshes and geometry sorting. Applying GPM to the comparison of construction alternatives in this study could have reduced the modeling work related to splitting 3D CAD objects into production objects of appropriate size. Based on 3D input models, GPM generates triangle meshes that can represent parts of CAD objects, where each triangle represents a work location of a crew in time. GPM could also have reduced the level of detail of both the CPM schedules and 3D models, and have facilitated the planning of work flow directions. As opposed to the approach of the 4D experiments where work flows were planned in the CPM environment, GPM uses the triangle mesh to define work flow directions, Figure 3. Planning work flow directions in the actual production model is considered more effectively than planning work flow directions with a CPM schedule. As a future extension of the conducted 4D study, a number of 4D simulations is planned with a developed GPM prototype, called GSim (Akbas 2004). The modeling process and the results from the GSim simulation can then be compared with the results from the conducted 4D study. 6.1.2 Feature-based 4D model Many production model objects are typically not included in 3D input models. A large number of objects in the production model of the 4D study were related to temporary structures and were mainly added for visual purposes. This required a considerable modeling effort in which the context of the 4D production model was not explicitly taken into account. Adding CAD objects to represent for example temporary structures, such as traditional form work elements, could be partly automated by using feature-based 4D models. Feature modeling is an approach whereby modeling entities termed features are utilized to provide improvements for common geometric modeling techniques (Kim 2004, unpubl.). In order to apply feature modeling techniques to temporary structure generation and planning, relevant features need to be identified and formalized. Research efforts to date have mainly focused on developing feature ontology for scheduling and cost estimation (StaubFrench 2003), but have not taken into account the generation and planning of temporary structures. Research work and developed prototype software by Kim (2004, unpubl.) show the potential to generate and plan temporary structures rapidly and efficiently. The application of this feature-based approach to generate and plan temporary structures in the conducted 4D study could have reduced the modeling work significantly and could have contributed to the quality of the temporary structure plan.

eWork and eBusisness in architecture, engineering and construction

188

In addition to experiments with GPM, a future study to evaluate the temporary structure plan of the conducted 4D study with a feature-based approach proposed by Kim (2004, unpubl.) is planned. 6.2 Input and output data One of the objectives of the 4D study was to explore the possibility to evaluate construction innovations in a realistic virtual environment. The modeling process and results from the 4D analysis show that virtual prototyping of certain construction processes is possible, but that specific construction operations are difficult to represent. The objective of the industrialized construction alternative was to show the potential of permanent form work in combination with the use of prefabricated reinforcement carpets and self compacting concrete. Specifying activities for all permanent form work elements led to highly detailed and complicated CPM schedules that became difficult to maintain. The specification of activities by using CPM schedules on this micro level, i.e. object level, even resulted in questions of how realistic this process model was. The CPM schedule contained finishto-start relationships and assumed sequential finality, i.e., predecessors had to be 100% complete before their successors could start (Tommelein 1999). This assumption proved to be too deterministic for simulation on object level. A more abstract process model was considered to be more realistic. It was found that there was no clear way to realistically simulate the benefits of prefabrication of reinforcement and self compacting concrete. Benefits of these production technologies, such as decrease in on-site activities, reduction of resource use and improved work environment could not be represented in the used 4D CAD models. These specific production technologies required support by graphs and other non-CAD data that could not directly be obtained from the 4D models. In combination with the study on creating a production model from a building model, by using GPM and feature-based modeling, also the relation between different levels of detail of input data for 4D models and possible output data will be examined. Especially the quantification of 4D model results needs to be addressed. These results could provide a better support to make specific comparisons between construction alternatives. 6.3 Application in practice Evaluation of multiple design and construction alternatives by using virtual models in a collaborative environment is considered useful to improve the performance of construction projects (Ballard 2002, Zabelle 1999). Results from this study show to some extent the power of using multiple virtual prototypes, but show at the same time limitations regarding required modeling effort and evaluation of results. These limitations result mainly from shortcomings in the applied 4D modeling environment, but result also from organizational shortcomings. One point of departure for the 4D study was the possible practical use of the software tools and 4D simulations in actual projects. The used client-server CAD environment was considered very promising and valuable by the project participants, but was considered too unstable and too slow for presentation of 4D model results on seminars. Standard

Modeling cast in place concrete construction

189

construction sequences were therefore recorded in AVI-format. 4D modeling functionality, specifically implemented for the 4D study in the client-server environment, was limited to basic functionality and did not provide users with an interactive environment. It was also not possible to rapidly extract data from the 4D models to make data analysis. Furthermore, the adapted approach for creation and maintenance of the 4D models was considered too labor and too resource intensive. Evaluating multiple construction alternatives by using virtual models in a collaborative environment is a fundamentally different way of how most traditional construction projects are pursued. Understanding of the technology and commitment of project teams to apply the technology in practice are examples of organizational prerequisites to derive benefits from virtual prototyping in 4D. Organizational issues have not been addressed in this study, but are considered critical for application in practice. 7 CONCLUSIONS The 4D modeling process and results show the potential, but show also limitations of virtual prototyping in 4D. Evaluating construction alternatives in a virtual environment can be an effective and cost efficient way to introduce and evaluate innovative construction processes and products, but has to be supported by a variety of comparative analyses. For this reason, the mainly graphical outcome of today’s 4D models has to be extended with methods that quantify the out-come of 4D models. The modeling process and required modeling effort currently limit the rapid evaluation of construction alternatives. Detailed 3D CAD models combined with detailed CPM schedules, lead to complex 4D models that are difficult to manage and maintain. A number of technologies is suggested that could facilitate and partly automate the generation of 4D models. Feature-based modeling is suggested to support the semiautomatic generation and planning of certain 3D CAD objects, such as representations of temporary structures. Geometry-based process modeling can reduce the required input level of detail of 3D CAD models and CPM schedules, and can facilitate the planning of work flows. Evaluation of construction alternatives in a collaborative environment is considered promising to support today’s interactive decision-making processes. However, application in practice implies a number of technical and organizational challenges. Collaborative modeling systems have to support multiple detailed CAD models and have to provide a stable environment to manage and maintain these models. Adapting the technology in organizations and construction projects requires organizational changes and commitment. Research on organizational issues is needed to facilitate further application of virtual prototyping in collaborative environments. ACKNOWLEDGEMENTS The financial support from SBUF—Development Fund of the Swedish Construction Industry, Betongindustri and the European Union’s structural funds is acknowledged.

eWork and eBusisness in architecture, engineering and construction

190

REFERENCES Akbas, R. 2004. Geometry-based modeling and simulation of construction processes, 150. PhD Thesis. Stanford University. Stanford, CA. Akinci, B., Fischer, M., and Kunz, J. 2002. Automated Generation of Work Spaces Required by Construction Activities. Journal of Construction Engineering and Management. 128(4):10. Ballard, G., Koskela, L., Howell, G., and Zabelle, T. 2001. Production system design in construction. 9th International Group for Lean Construction Conference. Singapore. 23–37. Ballard, G., Tommelein, I., Koskela, L., and Howell, G. 2002. Lean construction tools and techniques. in Best, R., and De Valence, G. (eds). Design and Construction—Building in Value:227–255. Oxford: Elsevier Science Ltd. Enterprixe 2002. Enterprixe White Paper. Enterprixe Software Ltd. Helsinki, Finland. Heesom, D., and Mahdjoubi, L. 2003. Dynamic Interactive Visualization of Construction Space Using 4D Techniques. 3rd International Postgraduate Research Conference in the Built and Human Environment. Lisbon, Portugal. Heesom, D., and Mahdjoubi, L. 2004. Trends of 4D CAD applications for construction planning. Construction Management and Economics, February 2004, 22, 171–182. February 2004(22):171–182. Jongeling, R., Olofsson, T., and Emborg, M. 2004. Product modelling for industrialized cast-inplace concrete structures. INCITE 2004—International Conference on Information Technology in Design and Construction. Langkawi, Malaysia. Kim, J. 2004, unpubl. Generating temporary structures with feature-based 4D models. 41. Department of Civil and Environmental Engineering, Stanford University. Stanford, CA. Koo, B., and Fischer, M. 2000. Feasibility Study of 4D CAD in Commercial Construction. Journal of Construction Engineering and Management. 126(4):251–260. Koo, B., and Fischer, M. 2003. Formalizing Construction Sequencing Constraints for Rapid Generation of Schedule Alternatives. 75. 28. Center for Integrated Facility Engineering, Stanford University. Stanford, CA. Li, H., Ma, Z., Shen, Q., and Kong, S. 2003. Virtual experiment of innovative construction operations. Automation in Construction. 12(5):561–575. Mallasi, Z., and Dawood, N. 2002. Registering Space Requirements of Construction Operations Using SitePECASO Model. CIB w78 conference 2002—Distributing Knowledge in Building. Aarhus School of Architecture, Denmark. 1–8. Staub-French, S., Fischer, M., Kunz, J. and Paulson, B. 2003. A generic feature-driven activitybased cost estimation process. Advanced Engineering lnformatics. 17(1):23–39. Tommelein, I.D., Riley, D.R., and Howell, G.A. 1999. Parade Game: Impact of work flow variability on trade performance. Journal of Construction Engineering and Management. 125(5):304–310. Zabelle, T.R., and Fischer, M.A. 1999. Delivering value through the use of three dimensional computer modeling. 2nd Conference on Concurrent Engineering in Construction. Espoo, Finland.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Pilot implementation of a requirements model Arto Kiviniemi* & Martin Fischer CIFE, Stanford University, Palo Alto, California, USA *VTT Building and Transport, Helsinki, Finland ABSTRACT: This paper reports on research at CIFE at Stanford University aiming to formalize a conceptual model to enable an active connection between the requirements for a building project and its building product model based design solution. The research is part of CIFE’s Virtual Design and Construction (VDC) framework. The main content of the model will be on the clients’ (owners’ and end-users’) requirements, but the model will cover also some external requirements set by the community and regulations. This paper compares two case studies and presents the pilot implementation of a requirements database based on the preliminary requirements model of room related client requirements. Our observation is that even a simple active link between the client requirements and design tools can increase the usage of requirements documentation throughout the design process and facilitate necessary updates of the client requirements.

1 INTRODUCTION 1.1 Overall goal The focus of our research is to create a conceptual model which enables active connections between requirements for a building project and the building product model based design solution. Our intuition is that the link could improve the requirements management process and also the quality of the end result; the building. 1.2 Problem description A building program specifying a project’s goals and requirements for all the spaces is the typical client requirements documentation in building projects, though there are also several other methods to capture client requirements. Regardless of the capturing method, the requirements, depending on the project type, consist of more or less detailed information about the required room properties; net area, activities, connections to other spaces, security, appropriate or desired materials, conditions like daylight, temperature, sound level, etc. Many requirements also “cascade”; e.g., create additional requirements to building elements bounding the space and systems serving the space. Moreover, an important part of the design process is that some requirements can be in conflict; the project team must often prioritize and make trade-offs between different requirements,

eWork and eBusisness in architecture, engineering and construction

192

which creates the need to update the requirements, and thus, manage and document the changes to the requirements and the design solution. In practice several factors make it virtually impossible that all the participants know and remember all the relevant requirements and especially their relationships to each other and to the design solutions. The main reasons for this argument are: – Amount and complexity of project information. – Duration of projects. – Designers need to work simultaneously on many projects. – Changing stakeholders in different project phases. – Shifting design focus, e.g., moving from overall problem solving to detailed technical solutions. After conceptual design the requirements documentation is usually not used actively in the current process, and often the evolving requirements are not even communicated to the whole project team (Kagioglou et al 1998). Thus, the changes are compared to, and decisions made based on, the previous design solutions. The current design tools do not support recording of client requirements or designers’ intent in the documents. Thus, the people deciding on the changes do not always even know the original intent, and the solution can “drift away” from the original goal without actual decisions to change the goal or understanding the contradiction between the proposed design and project goals. (Kiviniemi and Fischer 2004a, Kiviniemi and Fischer 2004c).

Figure 1. Model hierarchy.

Pilot implementation of a requirements model

193

1.3 Research scope Product models represent design solutions in a rich way (Froese 2002, BLIS 2004); the intent of our requirements model is to relate the client’s business processes to the design solution represented in the form of product models (Figure 1). The requirements structure is based on the traditional building programs. The direct requirements are limited to architectural design. The aggregation of indirect requirements to the bounding elements, e.g., walls, windows and doors, from these direct requirements is within the scope of our research. Detailed requirements for other design areas, like MEP and structural engineering, are not in the scope of the research, but the connection from architectural design to these design areas will be addressed. However, only the need for such a connection from the architectural design will be analyzed and shown, but the detailed content of these requirements is not in the scope of the research. 2 DRAFT CONCEPT 2.1 Draft model structure To address these limitations, we developed a concept that divides project’s information model into four linked sub-models presented in Figure 1. The reasons for this separation are: (1) Typically the design team produces several alternative design proposals, which all are expected to meet the defined requirements. Thus, having one requirements model linked to the alternative design models is a logical structure instead of multiplying the same requirements to different design alternatives, which would easily lead to requirements management problems. Similarly there can be several alternative production models and finally a separate maintenance model. All these sub-models should be connected to a virtual integrated product model, so that it is possible to access the content of the different models and compare the alternatives at any stage of the process. Our work focuses on the requirements model and its connection to the design model(s). (2) One “requirements instance” can relate to a number of separate instances with identical requirements in the product model. (3) The existing product model standard, Industry Foundation Classes (IFC) has been developed to describe mainly design solutions. Its current structure does not support requirements management well, neither does the internal structure of existing design software. In practice this means that most of the requirements data cannot be exchanged using current IFC files nor stored in the design software, but must be kept in a separate database. (4) The flexibility of the requirements structure is greater if the two models are separated and connected with a “thin” link. In this case, for example the only property needed for the link of space requirements is the ID in the space objects, which is supported by almost any design software. For indirect requirements the functional demand is to

eWork and eBusisness in architecture, engineering and construction

194

recognize the connection between bounding elements and spaces, which is supported by some commercially available product model based software. (5) Another reason for the separation is to make the distinction between requirements and properties clear; for example sound insulation is a requirement in the requirements database and a property in the product model. A further important observation is that the “requirements instances” in the requirements database have no physical locations, i.e., the requirements for bounding elements can relate to one space only. In the product model the bounding elements are always either between two spaces or part of the building envelope. This means that the requirements for the bounding elements must be aggregated from the requirements of the related spaces; they cannot be defined directly to the elements in the same manner as the space requirements relate to the spaces. 3 CASE STUDIES 3.1 Test cases To test the existing problems and possible solutions we used rapid prototyping. We analyzed two real building programs, implemented two test databases based on the results, and entered the project information. In the test cases the research concentrated on room related client requirements only, external requirements were not in the scope at this stage. The detailed results of the test cases are published in ICCCBE-X proceedings (Kiviniemi and Fischer 2004a) and also in a CIFE Working Paper (Kiviniemi and Fischer 2004c). This paper covers only the main conclusions from these case studies. The two projects were the ICL Headquarters project in Helsinki built in 1994–1996 and the on-going Lucas Center Expansion at Stanford University. The ICL Headquarters is a large office building consisting mainly of standard office rooms, but including also some special rooms and requirements. The Lucas Center Expansion is a small special laboratory consisting mainly of unique rooms with very little repetition. 3.2 ICL Headquarters program The ICL Headquarters’ building program was one document. The required areas were constantly compared to actual design solutions and the requirements file was constantly updated during the design process. The requirements documentation with respect to required room areas was coherent. The only identified problem was related to the structure used in the document; all classification codes and requirements were entered manually in each cell, which created the possibility for incoherent content and made updates more laborious. Use of references to one source data, e.g., simple inheritance structure, would prevent this problem.

Pilot implementation of a requirements model

195

3.3 Lucas center expansion Available LCE project documentation consists of a set of design sketches, drawings and MS Excel spreadsheets of different project stages, the architect’s requirements database (Claris Filemaker), meeting minutes, and technical specifications. The project was at the time of the study (November 2003) in the early construction stages. LCE’s Project Manager and Project Architect provided some insight on the project. The basic conclusion based on these interviews is that Stanford’s projects are generally well-managed and have clearly defined processes for different stages. However, as is typical in the AEC industry, the requirements capturing process is somewhat fuzzy, based strongly on meetings, where end-users and the project team are interacting trying to find solutions to specific problems. The decisions are recorded in the meeting minutes, and the room areas of each design stage are documented in MS Excel spreadsheets. The reasoning behind the changes and proposed solution becomes tacit knowledge and is “stored” only in the minds of the participants. The main problem categories in the requirements documentation for the LCE project were: – Lacking or different identifications of the rooms. – Contradictions in the different documents. – Incoherent descriptions of the same requirements. – Wrong or missing information. – Instead of actual spatial requirements the documents recorded the areas of the rooms in the design solution. – Documents specifying detailed technical requirements had no relation to the room related requirements documentation. 3.4 Conclusions of the test results The requirements documentation and process in the LCE project are a typical example of practices on current construction projects. Different parts of the requirements are stored in several documents, and there is no comprehensive document containing all needed information. In addition, the names and IDs for the rooms are often ambiguous, and similar requirements are formulated in different ways. This makes it difficult to connect requirements to the correct room even manually, and the use of ICT to manage the relations between the requirements and solutions is almost impossible. Though many of the mistakes in the LCE project were small, and probably caused little, if any, real problems to the people, who have been actively involved in the project, they are a clear indication of the general requirements management problem in the current process. To anyone, who joins the project later, it is very difficult and time consuming, sometimes impossible, to find out which requirements are correct and still relevant. Furthermore, someone who wonders about the changes, like the growth in the size of the project, will have great difficulty finding an answer in the project documents. Though only the required area information of the ICL Headquarters project was linked with the design solution, it provided some benefits. ICL’s Project Manager states: “Still today, over 9 years later, ICL Headquarters is the only project, where I got practically real time information comparing actual areas to the building program on a detailed

eWork and eBusisness in architecture, engineering and construction

196

level, and was able to follow constantly that the project design stayed within the allocated limits.” In addition, despite the simple approach taken in the ICL project to only link the requirements and the design information for comparing required and real areas, the coherent requirements information suggests that a link between requirements and design tools and the constant use of requirements information in the process could improve requirements management. 4 DATABASE STRUCTURE AND UI To explore the possible solutions to manage the room related requirements, we used rapid prototyping and implemented some different database structures to find a usable solution, which would: – Provide solutions to the problems identified in the LCE project. – Support inheritance of the room type requirements (ARqE) to rooms (IRqE) (Figure 2). – Enable in the next phase of the research a link between the requirements database and the product model (Figure 2). 4.1 Requirements database tests The user interface and database structure of the first pilot implementation were based mainly on the room program documents of LCE project. The implementation was made in MS Access 2002 database. The main criteria for the database structure were to provide a solution to the identified problems: – Unique IDs for the rooms; i.e., IRqE and all the rooms in the product model referencing it must share the same ID unambiguous identification. – Use of requirements types (ARqE) and inheritance efficient and easy maintenance and updating of repetitive requirements. – Use of user-definable enumeration (list of values) instead of free text coherent content. – No default values, which might inadvertently set wrong requirements. – Functionality to compare area requirements with areas in design documents. – Functionality to link external documents to the requirements database, e.g., to include also complex descriptive requirements, not only short text and numerical requirements.

Pilot implementation of a requirements model

197

Figure 2. Draft concept to link detailed room related requirements to a product model. As introduced in Figure 2 the key idea is the use of two main tables: “RoomTypes” (ARqE) and “Rooms” (IRqE). “RoomType” is an abstract requirement entity and ZRoom” is an instantiable requirements entity in the requirements database. Both have the same fields and references (Shared Requirements, ShR) with the following exceptions: – “Room” can reference a “RoomType” to inherit its requirements, but the opposite relation is not possible. – “Room” can have a relation to department and other room(s), but “RoomType” cannot have these relations (instance-specific properties, ISP). – The “Rooms” table contains a “NumberOfInstances” and “RoomName” fields, which are not in the “RoomTypes” table (ISP). – Only “RoomType” has RoomTypeDescription and RoomTypeDoc fields, (type-specific properties, TSP). The requirements used in the implementation are only one example of possible requirements, and do not cover all possible building types or use cases. However, they can be categorized in two main groups:

eWork and eBusisness in architecture, engineering and construction

198

– Single-value requirements (SVR), which can have only one value or reference for each room, like, for example, noise level, maximum number of occupants, maximum temperature, etc.

Figure 3. Elements of the pilot implementation and the relationship to existing software and processes. – Multi-value requirements (MVR), which can have a number of different values or references in each room, like, for example, activities, equipment, windows, etc. The separation of SVR and MVR defines the basic structure of the requirements database and is an important issue because of two reasons: (1) If all requirements would be defined and implemented as SVR types, the database structure would not allow use of an unlimited number of requirements for each room, which is necessary for some requirement types as described above. (2) If all requirements would be defined and implemented as MVR types, the possibility to give multiple values for all properties could cause contradicting requirements, like several different maximum areas. In addition, the database structure would be more complicated, which could create performance problems, and the user-interface to the data would be more difficult to understand and slower to use, if all values were in subtables. The RoomTypes were not used in the LCE project database, because the rooms are not based on any repetitive types; all rooms are defined as separate instances. In contrast, the ICL project is based on strong use of room types and this caused one change in the database structure. “RequiredNetArea” and “MaxOccupants”,

Pilot implementation of a requirements model

199

which were located in both the “RoomTypes” and “Rooms” tables in the LCE test, would have caused extensive duplication of similar type definitions with different area and occupant values. Thus, the database structure was changed so that these requirements were removed from the “RoomTypes” table and changed to instance-specific requirements in the “Rooms” table (Figure 4). Otherwise the same database structure, which was used in the LCE project test, also worked for the ICL Headquarters project and enabled recording of the requirements in a usable format; 782 physical room instances are stored in 186 requirements instances based on 51 RoomTypes. The maximum number of type references is 16, the average 3.8 and the median 2. The population of the database took about 3 hours, which can be seen as a reasonable effort. Figure 4 shows the “1_to_1” and “1_to_many” relations in the final pilot database. “Room-Type” and “RoomID” are the key links between different tables. This draft structure forces the user to define unique IDs for each requirements instance (Rooms), and all the “free text” requirements, like departments, adjacent rooms, equipment, activities, etc. are based on user-definable lists (enumerations), which prevents slightly different requirements descriptions or references to non-existing rooms; all problems we identified in the LCE project data.

Figure 4. Pilot database structure.

eWork and eBusisness in architecture, engineering and construction

200

Figure 5. Demo version of requirements management userinterface; Room type definitions. Based on the experiments with these two different room programs, the current structure appears to be a sufficient basis for further work at this stage of our research. Based on the structure, we developed a preliminary conceptual requirements model, which is published in the GCADS workshop proceedings (Kiviniemi and Fischer 2004b). 4.2 Connection to a product model The actual connection of the requirements database to the product model based design software was not implemented, orily a mock-up of a connection from the design application to the Access database was developed. By selecting objects in the design software, e.g., rooms and bounding elements, the user can see all the related requirements in the requirements database (Figure 5 and Figure 6). “RoomID” is the connecting element between the requirements database and the product model. The room instances in the product model are connected directly, but the bounding elements related to the rooms are identified in the product model and the connection to the requirements database is based on the “RoomID” of identified rooms. The user interface mock-up shown in Figure 5 and Figure 6 illustrates how to access the requirements database from the design software by adding a requirements view to its user interface. Depending on the use scenario, the modifications of the requirements from the design interface can be either allowed or denied; in some projects the client might

Pilot implementation of a requirements model

201

delegate the requirements management to the designers, in some projects it might be the task for the PM or the client’s own representative. The selected database approach enables independent access control for the requirements database. 5 FUTURE WORK The research is still continuing. At the next stage we will analyze several other building programs to find a

Figure 6. Demo version of requirements management userinterface; wall requirements. relevant structure for the requirements model. Some requirements are common to practically all buildings, like, for example, required area, activities in the space, connections to other spaces, etc. Some requirements are specific only to some building types, like, for example, exact limits for minimum and maximum temperatures and moisture; they are common for laboratories, museums, demanding technical facilities, etc., but not defined for most buildings (Table 1). We argue that all these different types of requirements can not be standardized. Thus the goal of our research is to identify a reasonable set of common requirements within the defined scope and create a flexible framework, conceptual model, which enables also project specific requirements. We expect that our research will also create the basis for future research topics, like, for example:

eWork and eBusisness in architecture, engineering and construction

202

Different building types and process phases: The scope of our research covers a few building types only. Our intuition is that the same conceptual model could be applied to most buildings, but because of the different requirements the database and UI implementation might be different In addition, our research covers only design, a short period of the process, the use of the requirements model in other parts of the process, like, construction, FM, etc., is not covered in detail, though the same principles are possibly applicable. Technical systems and other design areas: The designers’ role in defining detailed technical requirements for technical systems is more dominant than in the architectural design, and LBNL’s research in this area provides another view on building requirements management (LBNL 2003). However, there is no link between the technical requirements for systems and the building product model. Our research identifies some connections to technical systems, but the formal link between these two requirements views will need further research, as do requirements link and management in other design areas, like structural engineering. Requirements history: One interesting related research area is the requirements history; how the requirements evolve during the process. Our research proposes a conceptual model for requirements, which will provide a conceptual basis to store all the requirements changes during the process in the database. How to implement such a historic perspective of requirements management in detail and which functionalities the UI would need, could be interesting areas for further development.

Table 1. Requirements analysis results from the LCE and ICL project building programs. Property

Requirement Room Room One Many Data Type type

Bounding Systems LCE, LCE, ICL Average elements PM PA (%) (%) (%) (%)

Identification and overall definition RoomID

m

x

UID, string

Room Name

o

x

Room Type

o

m

o

o

Room Descrip tion

o

Document

x

x

62

92 100

88

String

100

100 100

100

x

UID, string

46

100

73

o

x

String

o

x

Hyper link

o

x

Enum

92 100% 100

98

m

x

Integer

100 100% 100

100

Individual properties and requirements

Depart ment Number Of

Pilot implementation of a requirements model

203

Rooms Required Area

o

x

Real

Max Occupants

o

x

Integer

x

x

100% 100

100

100

50

Basic properties MaxNoise Level

o

o

Integer

Sound lnsulation

o

o

Enum

x

x

SecurityClass

o

o

Enum

x

x

38

19

Connections, activities, furniture, equipment, doors and windows Connections

o

x

Refto UID

Assigned Activities

o

o

x

Enum list

Furniture

o

o

x

Enum list

Equipment

o

o

x

Enum list

Doors

oo

x

Enum list

Windows

o

x

Enum list

Floor

oo

x

Walls

oo

Ceiling

o

46 x

28

37

85

42

62

731

x

38

x

x

100

50

x

x

Enum

92

46

x

Enum

100

50

o

x

Enum

100

50

Ceiling height o

o

x

Real

x

92

46

o

o

x

Hyper link

Natural Light

o

o

x

Yes/ No

x

77

38

NoWindows

o

o

x

Yes/ No

Dimmable

o

o

x

Yes/ No

o

3

21

Finishes

Document Lighting

x

x x

eWork and eBusisness in architecture, engineering and construction

204

Darkenable

o

o

x

Yes/ No

x

Warning Light

o

o

x

Yes/ No

x

Ambient Light Level

o

o

x

Real

x

o

o

x

Hyper x link

x

Min Temperature

o

o

x

Real

x

x

46

Max Temperature

o

o

x

Real

x

x

46

MinAir Change Rate

o

o

x

Real

x

92

46

MaxAir ChangeRate

o

o

x

Real

x

Min Humidity

o

o

x

Real

x

x

Max Humidity

o

o

x

Real

x

x

AirRecycle

o

o

x

Yes/ No

x

62

31

o

o

x

Hyper x link

x

Document Environmental conditions

Document

23 2

Verification: Some requirements are “fuzzy”, verbal or otherwise only human interpretable descriptions, but some have an exact content. The possibility to use the exact requirements for automated verification, i.e., how well the design meets the requirements, is a potential usage of the requirements model. Verification of the “fuzzy” requirements must include designers’ interaction, but the designer’s or project manager’s confirmation that the requirements are met, could be part of the database and serve as a formal project history. 6 CONCLUSIONS The goal of our research is to develop and test a method to create an active link between requirements and product model based design tools. At this stage the research has documented at least some aspects of the requirements management problem, and tested one possible model for a requirements database structure. The final, anticipated scientific contributions of the research are: – Documentation of the requirements management problem in the design process.

24

Pilot implementation of a requirements model

205

– Documentation and analysis of the different requirements types. – Specification of a conceptual requirements model based on the analysis. – Specification for a link between client requirements and product model objects. – Specification for the aggregation of indirect requirements from the direct client requirements to the building elements. – Extended BLIS view “Room Program -> Architectural Design” for the IFC product model implementation. The expected main contribution on a practical level is the development of a conceptual model, which enables software supporting requirements management during the design process and interaction between the design solutions and requirements. REFERENCES Froese, T. 2002. Current Status and Future Trends of Model Based Interoperability, eSM@rt 2002 Conference Proceedings Part A, University of Salford, pp. 199–208 Kagioglou, M., Cooper, R., Aouad, G., Hinks, J., Sexton, M. & Sheath, D. 1998. A Generic Guide to the Design and Construction Process Protocol; University of Salford Kiviniemi, A. & Fischer, M. 2004a. Requirements Management Interface to Building Product Models, Proceedings ICCCBE-X, page 252 Kiviniemi, A. & Fischer, M. 2004b. Room related requirements model concept in building product model environment—PREMISS project, GCAD’04 symposium, Carnegie Mellon University Kiviniemi, A. & Fischer, M. 2004c. Requirements management interface to building product models, Stanford University, CIFE Working Paper LBNL 2003. Lawrence Berkeley National Laboratory, Design Intent Tool, http://ateam.lbl.gov/DesignIntent/home.html

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

A combined product-process model for building systems control A.Mahdavi Department of Building Physics and Building Ecology, Vienna University of Technology, Vienna, Austria ABSTRACT: In order to suffice the requirements of building systems control applications, the underlying representation must combine building product information with building controls information. Currently, there is a lack of systematic building representations that would integrate aspects of product and process. This paper explores ways of coupling of a controloriented process model with a building product model. An approach is described for the automated rule-based generation of a representation for building systems control applications.

1 INTRODUCTION 1.1 Problems in building systems control Currently, building systems controllers (for heating, cooling, ventilation, lighting, etc.) operate in terms of individual system components at several levels. While this allows, in principle, for a distributed implementation of control logic, it also leads to the configurations of environmental systems as isolated sub-systems. Thus, devices affecting the same control zone are seldom integrated. Likewise, in most buildings, the level of vertical integration of local and central systems is insufficient. These problems are aggravated due to the contingencies associated with the boundary conditions of system operation, e.g. dynamic changes in the outdoor conditions as well as building occupants’ activities and control actions. There is generally a lack of representations for integrating sub-systems with each other and with building product models. Most commercially available environmental control systems for buildings do not offer explicit representational frameworks either to systematically capture multiple control processes and their interactions or to map those processes onto target building product model entities (i.e. control impact zones). 1.2 Product and process Numerous representational schemes (product models) have been proposed to describe building elements components, systems, and structures in a standardized fashion (Augenbroe 1995, IAI2004). Thereby, one of the main motivations has been to facilitate hi-fidelity information exchange between agents involved in the building delivery process (architects, engineers, construction people, manufacturers, facility managers, users). The

A combined product-process model for building

207

representational stance of most building product models is decompositional and static (see Figure 1 as an example of a—schematically illustrated—building product model). In contrast, building control requires representational systems capable of capturing procedural sequences of events, decisions, and actions. Toward this end, the underlying representation must combine detailed building product information with building controls process information. Currently, there is a divide between modes and styles of control system representation in the building control industry and representational habits in architecture and building science. Specifically, there is a lack of systematic building representations that would unify building product, behavior, and control process information. This paper explores ways of coupling a control-oriented process model with a building product model. 1.3 Paper overview Section 2 provides a high-level instance of a combined process-product model. Section 3 demonstrates how the control process model can be created using a logical and coherent method, so that it could be used for a diverse set of building control applications. A set of rules are presented that allow for the automated generation of the control system model. Section 4 demonstrates the application of the representational framework and its rulebased generation using the concrete example of a test space. Section 5 includes the conclusions of the paper.

Figure 1. SOM (shared object model), an example of a building product model developed in the course of the SEMPER project (Mahdavi 1999, Mahdavi et al. 1999a).

eWork and eBusisness in architecture, engineering and construction

208

2 INTEGRATION 2.1 Control as process As opposed to abundant literature in building product modeling, there is a lack of an explicit ontology for the representation of building control processes. Table 1 includes a glossary of fundamental terms (together with definitions and examples) that are relevant to building systems control representation. A basic control process involves a controller, a control device, and a controlled entity (see Figure 2). An example of such a process is when the occupant (the controller) of a room opens a window (control device) to change the temperature (control parameter) in a room (controlled entity). 2.2 A high-level combined product-process scheme It is useful at this point to explore ways of coupling the basic process model depicted in Figure 2 with an instance of the previously mentioned building product models (Figure 1). Figure 3 illustrates a high-level expression of such a combined building product and control model. While certain instances of the product model such as building, section, space and enclosure constitute the set of controlled entities in the process view, other instances such as aperture or technical systems and devices fulfill the role of control devices. 2.3 Zones, sensors, and devices Both the basic control process model depicted in Figure 2 and its embellished version with elements of a product model (Figure 3) are rather schematic. They must be extended and augmented to capture the details of realistic control processes. To achieve a more detailed and operationally effective representational integration of building product and process aspects, this scheme must be realized within the context a two-fold hierarchy, one pertaining to the building product classes and the other pertaining to controller classes. Key to the communication between the two hierarchies is the Janus-faced notion of the “controlled entity” (or “control zone”). From the product model view point, a control zone corresponds either directly to a product model entity (such as space) or to an abstract entity derived by partition or aggregation of product model entities (e.g. a workstation within a room, a collection of windows in a facade). From the control model point of view, a zone is the abstract object of control (controlled entity) whose controlrelevant attribute (control parameter) is monitored via corresponding sensors. As Figure 4 illustrates, zones can be viewed as fluid and reconfigurable entities whose spatial extension may be mapped back to (properly partitioned or aggregated) components of a building product model. Devices and sensors can be mapped back to a product model in terms of physical objects (e.g. in terms of technical elements as per Figure 1).

A combined product-process model for building

209

Table 1. Terms, definitions, and instances in building control (Mahdavi 2001a). Term

Definition

Instance

Controller

Decision-making agent: influences the controlled entity via a control device

People, software, thermostat

Control objective

Goal of the control action

Maintaining a set-point temperature

Control device

Is used to influence the controlled entity

Window, luminaire, HVAC system

Actuator

Interface between controller and control device

Valve, dimmer, people

Control device state

Control-relevant attribute of control device

Closed, open

Controlled entity

Object of control (assumed target or impact zone of a control device)

Room, floor, building

Control parameter

Indicator of control-relevant state of controlled entity

Room temperature, illuminance on working plane

Sensor

Reports the state of: control parameters, environmental and occupancy conditions, control devices

Thermometer, illuminance sensor, electricity counter

Control action Change in the control device state

Opening windows, turning on lights

Control state space

Possible positions of a valve, a dimmer, or a window

The logical space of possible positions of a (or a number of) control device(s)

Figure 2. A general control scheme. Whilst the building product modeling community is quite experienced in dealing with complex hierarchies of product model components, explicit hierarchical schemes for the representation of control processes are far less developed. Strictly speaking, the

eWork and eBusisness in architecture, engineering and construction

210

“controller” entity as shown in the basic schemes of figure 2 and 3 applies only to a “device controller” (DC), i.e. the dedicated controller of a specific device. These schemes stipulate that a DC receives control entity’s state information directly from a sensor, and, utilizing a decision-making functionality (e.g. a rule or an algorithm that encapsulates the relationship between the device state and its sensory implication), sets the state of the device. Real world building control problems are, however, much more complex, as they involve the operation of multiple devices for each environmental system domain and multiple environmental system domains (e.g., lighting, heating, cooling, ventilation). An appropriate representation of control processes must thus capture the relationships between primary

Figure 3. A high-level building product and control process scheme.

A combined product-process model for building

211

device controllers and various layers of higher-level controllers (or meta-controllers). Moreover, it must be created based on a logical and coherent method, allowing ideally for the automated generation of the control process model. The next section of the paper describes such a method.

Figure 4. Zones as the coupling links between building product and control process hierarchies.

3 GENERATION 3.1 Device and meta-con trollers As such, the complexity of building systems control could be substantially reduced, if distinct processes could be assigned to distinct control loops. However, controllers for various systems and components are often interdependent. A controller may need the information from another controller in order to devise and execute control decisions. For example, the building lighting system may need information on the buildings thermal status (e.g. heating versus cooling mode) in order to identify the most desirable combination of natural and electrical lighting options. Moreover, two different controllers may affect the same control parameter of the same impact zone. For example, the operation of the window and the operation of the heating system can both affect the temperature in a room. In such cases, controllers of individual systems cannot identify the preferable course of action independently. Instead, they must rely on a higher-level controller instance (i.e., a “meta-controller”), which can process information from both systems toward a properly integrated control response. We conclude that the multitude of controllers in a complex building controls scheme must be coupled appropriately to facilitate an efficient building operation regime. Thus, control system features are required to integrate and coordinate the operation of multiple devices and their controllers. Toward this end, control functionalities must be distributed

eWork and eBusisness in architecture, engineering and construction

212

among multiple higher-level controllers or “meta-controllers” (MCs) in a structured and distributed fashion. The nodes in the network of device controllers (DCs) and metacontrollers (MCs) constitute points of information processing and decision making. In general, “first-order” MCs are required: (i) to coordinate the operation of identical, separately-controllable devices and (ii) to enable cooperation between different devices in the same environmental service domain. A simple example of the first case is shown in Figure 5, where an MC is needed to coordinate the operation of two electric lights to achieve interior illuminance goals in a single control zone. Figure 6 shows an example for the second case: moveable blinds and electric lights are coordinated here to integrate daylighting with electric lighting.

Figure 5. Meta-controller for individually controllable identical devices.

A combined product-process model for building

213

Figure 6. Meta-controller for different devices addressing the same control parameter.

eWork and eBusisness in architecture, engineering and construction

214

Figure 7. Schematic floor plan of the test spaces. In actual building control scenarios, one encounters many different combinations of the above instances. Thus, the manner in which the control system functionality is distributed among the controllers must be explicitly configured. The control process model must be created using a logical, coherent, and reproducible method, so that it can be used for a diverse set of building control applications. Ideally, the procedure for the generation of such a control process model should be formalized and automated, given its complexity, and given the required flexibility to dynamically accommodate changes over time in the configuration of the controlled entities, control devices, and their respective controllers. 3.2 Generative rules A set of constitutive rules has been developed and tested that allows for the automated generation of the control system model (Mahdavi 200 la, Mahdavi 2003, Mertz & Mahdavi 2003). Such a model can provide a template (or framework) of distributed nodes which can contain various methods and algorithms for control decision making. Specifically, four model generation rules are applied successively to the control problem, resulting in a unique configuration of nodes that constitute the representational framework for a given control context. The first three rules are generative in nature, whereas rule 4 is meant to ensure the integrity of the generated model. The rules can be stated as follows: (i) Multiple devices of the same type that are differentially controllable and that affect the same sensor necessitate a meta-controller. (ii) More than one device of different types that affect the same sensor necessitates a meta-controller. (iii) More than one first-order meta-controller affecting the same device controller necessitates a second-order (higher-level) meta-controller.

A combined product-process model for building

215

(iv) If in the process a new node has been generated whose functionality duplicates that of an existing node, then it must be removed. Any resulting isolated nodes must be reconnected.

4 ILLUSTRATION 4.1 Control system representation The following example illustrates the application of the rules introduced in the previous section (Mertz & Mahdavi 2003). The scenario includes two adjacent rooms, each with four luminaires and one local heating valve, which share a set of exterior moveable louvers for daylight and insolation control (see Figure 7). Hot water is provided by the central system, which modulates the pump and valve state to achieve the desired water supply temperature. In each space, illuminance and temperature are to be maintained within the set-point range. This configuration of spaces and devices stems from an actual building, namely the Intelligent Work-place (IW) at Carnegie Mellon University, Pittsburgh, USA (Mahdavi et al. 1999b). An effective way to define control zones (controlled entities) is to describe the association between the sensors and devices. From the control system point of view, controlled entities are “represented” by sensors, and the influence of devices on the controlled entities is monitored via sensory information. In the present example, an interior illuminance sensor (E) and a temperature sensor (t) are located in each space. The sensors for Space-1 are called E1 and t1, and those for Space-2 are called E2 and t2. In Space-1, both the louvers and electric lights can be used to meet the illumination requirements. As shown in Figure 8, Sensor E1 is influenced by the louver state, controlled by DC-Lo1, as well as by the state of four electric lights, each controlled by a DC-EL. Similarly, both the local valve state and the louver state influence the temperature in Space-1 (t1). Analogous assumptions apply to Space-2. Once the associations of the devices and sensors have been determined and the control zones (controlled entities) have been defined, the generation rules can be applied to the control problem, resulting in the representation of Figure 9. A summary of the application of Rules 1, 2, and 3 is shown in Table 2. As to the application of rule 1, four nodes, namely DC-EL1, EL2, EL3, and EL4 are of the same device type and all impact sensor E1. Thus, an MC is needed to coordinate their action (MC-EL_1). Similarly, regarding the application of rule 2, both DC-Lo1 and DCVa1 impact the temperature of Space-1. Thus, MC-Lo_Va_1 is needed to coordinate their action.

eWork and eBusisness in architecture, engineering and construction

216

Table 2. Application of Rules 1, 2, and 3 toward the generation of a control model for a test space (see text and Figures 7 to 9). Multiple controllers

Affected sensor

Affected device

Metacontroller

E1

N/A

MC-EL_1

E2

N/A

MC-EL_2

Lo1, Va1

t1

N/A

MC-Lo Va_l

Lo1, Va2

t2

N/A

MC-Lo_Va_2

EL_1, Lo1

E1

N/A

MC-EL_Lo_1

EL_2, Lo1

E2

N/A

MC-EL_Lo_2

N/A

Lo1

MC-II

Application of Rule 1 EL1, EL2, EL3, EL4 EL5, EL6, EL7, EL8 Application of Rule 2

Application of Rule 3 EL_Lo_1, EL_Lo_2,

EL Lo Va_1

Lo_Va_1, Lo_Va_2

Figure 8. Association between sensors and devices in the test spaces (cp. text and figure 7).

A combined product-process model for building

217

Figure 9. An automatically generated control model for the test spaces (cp. text and figures 7, 8). As to rule 3, four MC nodes control the DC-Lo1 node. Thus, their actions must be coordinated by an MC of second order, namely MC-II EL_Lo_Va_1. In this example, Rules 1, 2, and 3 were applied to the control problem to construct the representation. Using this methodology, a unique scheme of distributed, hierarchical control nodes can be constructed. In certain cases, however, the control problem contains characteristics that cause the model not to converge toward a single top-level controller. In these cases, Rule 4 can be applied to ensure convergence. Rule 4 is used to ensure that model functionality is not duplicated. Thereby, the means of detecting a duplicated node lies in the node name. Since this may create hierarchically isolated nodes, rule 4 also requires that such nodes be reconnected. The following example illustrates the application of this rule. Figure 9 shows a model that was constructed using rules 2 and 3. The application of these rules is summarized in Table 3. Rule 1 does not apply in this case because there are three distinct device types involved. As to the application of rule 2, DC-EL1 and DC-BL1 both impact the state of E1 and thus MC-BL_EL_1 is needed to negotiate between them. Three MC nodes are created in this manner. When Rule 3 is applied, three second-order MCs are created. It is apparent that the model will not converge. Moreover, the three nodes have the same name: MC-BL_EL_Lo. This is an indication of duplicated functionality (of coordinating devices BL, EL, and Lo). Thus, applying rule 4, nodes MC-BL_EL_Lo_2 and MCBL_EL_Lo_3 are removed

eWork and eBusisness in architecture, engineering and construction

218

Figure 10. Application of Rule 4 (see also Table 3). and node MC-BL_Lo_1, which is left without a parent node, is connected to the MCBL_EL_Lo_1. The above illustrations were meant to provide a basic understanding of the proposed approach toward the rule-based generation of control-oriented building process models. This model generation approach can be automated and enables, thus, the control system to effectively respond to changes in spatial organization, control zone configuration, and control components. Moreover, the systematic and explicit definition of sensors, zones, devices, controllers, and their relationships, together with the aforementioned generative rules provide a control systems design environment that has been shown to be advantageous in terms of scalability and robustness. Various model generation attempts pertaining to realistic building and system considerations (with multiple systems and multiple spatial levels) have consistently led to reliable and robust control system schemes.

A combined product-process model for building

219

4.2 A note on model-based control methods The integrated representation introduced in this paper is syntactic in nature. It does not provide specific solutions to address issues of control semantics. Rather, it provides a flexible framework (a template as it were) for implementing different kinds of control semantics. Given its systematic hierarchical structure, the representation is specially suited for the implementation of distributed and modular control logic routines. Such routines include also the class of so-called model-based control methods. Model-based control methods aim at the behavioral description of the reaction of controlled entities to various positions of pertinent control devices given a set of contextual conditions (i.e. climate, occupancy).

Table 3. Application of Rules 2 and 3 toward the generation of the control representation of Figure 9. Multiple Controllers

Affected Sensor

Affected Device

MetaController

EL1, BL1

E1

N/A

MC-BL_EL_1

EL1, Lo1

E2

N/A

MC-EL_Lo_1

BL1, Lo1

E3

N/A

MC-BL_Lo_1

E1

DC-EL1

MC-BL_EL_Lo_1

E2

DC-Lo1

MC-BL_EL_Lo_2

E3

DC-BL1

MC-BL_EL_Lo_3

Application of Rule 2

Application of Rule 3 BL_EL_1, EL_Lo_1 EL_Lo_1, BL_Lo_1 BL_EL_1, BL Lo 1

Both rules and simulations can be applied to capture (and predict) system behavior. In rule-based control, a simple statement describes the control function used to make decisions. As an example, a rule used within a DC node can define the relationship between the state of a device and its corresponding impact on the state of the sensor monitoring the controlled entity. Rules can be developed through a variety of techniques. For example, rules can rely on the knowledge and experience of the facility managers, the measured data in the space to be controlled, or logical reasoning. Simulation-based control (Mahdavi 2001b) can be used for building control within the proposed representational framework through the following procedure: (i) Multiple potential control device states are considered in the pertinent DC node; (ii) The resulting device state space is analyzed via real-time simulation runs; (iii) Simulation results are evaluated and ranked according to applicable objective functions; (iv) Devicecontroller implements the most desirable device state.

eWork and eBusisness in architecture, engineering and construction

220

Rule-based and simulation-based control algorithms and methods can “animate” the control system representation resulting in a versatile systems control environment. Such an environment has the potential to simultaneously address: (i) The effects of control actions on multiple zonal performance indicators (control parameter), (ii) The influences of devices in multiple domains (heating, cooling, lighting, etc.), (iii) Conflicts amongst devices used to control multiple zones, (iv) Cooperation between local and central systems, (v) Multiple control objective functions. 5 CONCLUSION This paper presented an approach to establish an adequate framework for the combined representation of building product and process aspects. In this representation, target entities of control actions (controlled entities or zones) act as the coupling links between parallel hierarchies of building product classes and building controller classes. The building control hierarchy can be generated automatically via a set of four rules. Starting point for this generation process is the definition the controlled entities. This is achieved in that explicit associations between devices and sensors are established. The generated control representation includes various layers of multiple nodes that embody primary device-controllers and higher lever controllers (meta-controllers). Multiple expressions of distributed control semantics can be accommodated in such nodes. Promising algorithmic candidates for such distributed control logic implementations include model-based (rule-based and simulation-based) control routines. To improve the applicability of the proposed approach, work is under way to address issues of building model maintenance. Specifically, technology candidates for scalable and pervasive monitoring of model entities are being examined so as to bestow upon the—typically complex—building models the capability to update and reconfigure themselves autonomously. ACKNOWLEDGEMENT The work presented in this paper is support in part by the Austrian Science Foundation (FWF), Grant number: P15998-N07. REFERENCES Augenbroe, G. 1995. COMBINE 2, Final Report [online]. Commission of the European Communities, Brussels, Belgium. Available from: http://dcom.arch.gatech.edu/bt/Combine/my_www/document.htm IAI 2004. International Alliance for Interoperability [online]. Website. Available from: http://www.iai-international.org/iai_inter-national/ Mahdavi, A. 2003. Modell-basierte Steuerungsstrategien für “selbstbewusste” Gebäude. Gesundheits-Ingenieur. Oldenbourg Industrieverlag München. Heft 5. ISSN 0932–6200. pp. 234–244.

A combined product-process model for building

221

Mahdavi, A. 2001a. Aspects of self-aware buildings. International Journal of Design Sciences and Technology. Europia: Paris, France. Volume 9, Number 1. ISSN 1630–7267. pp. 35–52. Mahdavi, A. 2001b. Simulation-based control of building systems operation. Building and Environment. Volume 36, Issue 6, ISSN:0360–1323. pp. 789–796. Mahdavi, A. 1999. A comprehensive computational environment for performance based reasoning in building design and evaluation. Automation in Construction 8 (1999) pp. 427–35. Mahdavi, A., Ilal, M.E., Mathew, P., Ries, R., Suter, G. & Brahme, R. 1999a. The architecture of S2. Proceedings of Building Simulation ‘99. Sixth International IBPSA Conference. Kyoto, Japan. Vol. III. ISBN 4-931416-03-9. pp.1219–1226. Mahdavi, A., Cho, D., Ries, R., Chang, S., Pal, V., Ilal, E., Lee, S. & Boonyakiat, J. 1999b. A building performance signature for the “intelligent workplace”: some preliminary results. Proceedings of the CIB Working Commission W098 International Conference: Intelligent and Responsive Buildings. Brugge. ISBN 90-76019-09-6. pp.233–240. Mertz, K. & Mahdavi, A. 2003. A representational frame-work for building systems control. Proceedings of the Eight International IBPSA Conference. Eindhoven, Netherlands. Vol. 2. ISBN 90-386-1566-3. pp. 871–878.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

FIDE: XML-based data model for the spanish AEC sector J.M.Molina & M.Martinez AIDICO, Valencia, Spain ABSTRACT: The construction sector is very peculiar, it has some features that make it special and different from other industrial sectors. Firstly it is a highly fragmented sector, where 96% of the sector is made up of SMEs with less than 20 workers, and with a very small market quote. Secondly it is a sector of one-of-a-kind projects. And finally, each project brings together several actors from different areas. These features throw up the need for a common ‘language’ to facilitate the data exchange amongst the different stakeholders. Some interesting initiatives are being carried out at the international level in this line. In this paper we present the FIDE initiative, where the Spanish Administration has promoted the work to develop a PDM for the Spanish construction sector.

1 INTRODUCTION The exchange and integration of the information among the different stakeholders who participate in the processes of projecting and constructing public and private buildings and infrastructures (architects, engineers, constructors, manufacturers, laboratories …) are critical points that the construction industry must approach for being able to benefit from the enormous potential of productivity increase that the application of the Information & Communications Technology do provide. To date it exists no reference framework in Spain for the integration of the information in the construction process, neither for the compatibility of the existing software applications in the market, nor it has been considered a model or standard system of common data exchange within the sector in the Business-2-Administration arena. The usage of a common data model will allow a drastic reduction in the use of resources by all the involved agents. This specially applies for the Public Administrations in their task of the management and control of the information, documents and files generated during the construction process. The Administration must play therefore a fundamental role in the promotion and use of new technologies in the construction sector, being one of the main beneficiaries of its use, since it may enormously optimise the administrative processes which consume important resources as a result of an inefficient management of exchanging information. The FIDE model focuses on the scope of the Spanish National Technical Building Code. The Technical Building Code (TBC) is the normative framework that establishes the safety and habitability requirements of buildings set out in the building Act (LOE) [1].

Fide: Xml-based data model

223

To promote innovation and technological development, the TBC has adopted the most modern international approach to building norms: Performance-Based Codes or objectives. The use of these new regulations based on performance calls for the configuration of a more flexible environment, easily updated in accordance with the development of techniques and the demands of society, and based on the experience of traditional norms. Its development is coordinated at national level through a supra-regional stable Working Group that establishes the bases for its development and that coordinates and controls the extensions of the model, establishing approval mechanisms and integration of partial developments made by third parties within the general structure of FIDE, guaranteeing therefore the scalability of the model and the interoperability between different scopes of the Technical Code. FIDE model is public and open. In addition, its foundations have been established taking into account the possible relations with the most internationally spreaded standards and data models, like the IFC from the IAI [2]. This will facilitate the interrelation between FIDE and these international standards, thus fostering its compatibility and usability. This way FIDE will take profit of the existing tools and developments existing in the market developed for the IFC data model. For this reason FIDE will be widely spread not only at national level, but also at international level, showing it as example of good practices in the sector. The work done so far in FIDE has generated not only technical results, but what is more important, a proposal of a Law project for the setting up of the legal framework and procedures for the implementation of the initiative and the assurance of its general impact in the sector. The FIDE project has developed medium and long term plans to ensure the continuity of the initiative and to create the foundations for the sustainable development of the model, as well as to increase the awareness in the sector of the use of data models standards. The paper is structured as follows: Section 2 describes the objectives of the development of the model. Section 3 shows the methodology used in the development, including management and organization issues as well as technical issues. Section 4 gives the flavour of the work done in the technical part with the model development. Finally, Section 5 summarizes the conclusions and lessons learnt from the work as well as the near fiiture steps. 2 OBJECTIVES The main objective of the FIDE initiative is the development of a common product data model for the Spanish Construction sector. A major concern, although is to keep the compatibility with the existing initiatives at international level. The objective of FIDE can be splitted into two main issues: firstly the development of the model itself, and secondly the establishment of the necessary procedures for its maintenance and quality assurance. The main trigger for such a development is the need for a common framework for the different stakeholders in the sector to exchange information. One of the most benefited actors, and in fact the main promoter, is the Administration. The Administration is in the

eWork and eBusisness in architecture, engineering and construction

224

very centre of the data exchange. They have to receive plenty of documentation related to the construction process: building licence queries, quality control documents, health and safety assurance reports, etc. Each document has to be processed according to a repetitive established procedure. At the moment this is done manually. The use of a known standard digital format will allow them to process this documentation in an automatic manner. Furthermore, the Administration has the power to make it compulsory for the rest of the stakeholders to use this data model for the delivery of the required documents. On the other hand, there are also some important benefits for the industry side. In case they use this common data model the information reusability increases, thus improving the efficiency of the construction process. Also different actors collaborating within the framework of a given construction project can take profit of the file sharing, thus reducing the repetition of data introduction in different applications and improving, again, the efficiency of the process. This becomes directly into economic benefits for the sector stakeholders Finally, the existence of a broadly accepted and spreaded product data model will be the key to the development of software applications for the sector. These applications will take profit of this common language to facilitate the re-usability of information, the automatic processing of data, etc. So one of the intentions of the consortium is to set up the basis for the implementation of such applications by third parties as soon as the industry demands them. To sum up, the objectives of the FIDE initiative can be enumerated as follows: – To foster the construction sector development by improving the efficiency of the current ways of working. – To improve the current communication channel between the sector stakeholders and the Administration. – To provide the sector, specially the Administration, with a base for the later development of tools based upon it. – To offer international interoperability by following the main international standards. – To facilitate the interoperability between the sector stakeholders: promoters, designers, constructors, material provider, software vendors, etc., including the Public Administrations, independently of the computer applications used for planning, designing, estimating, and covering administrative management, authorizations procedures, and other purposes.

3 METHODOLOGY 3.1 Introduction This section describes the methodology that has been followed for the development of the FIDE model. The section has been structured in three parts: firstly the management structure that was created is described. Then the model maintenance and extension procedures that were established are described. In both cases the main functions and aims for each component of the structures are defined. Finally the technical issues are discussed, explaining and justifying the main technological decisions taken in the model implementation and the tools used.

Fide: Xml-based data model

225

3.2 Management structure In order to keep control of the model evolution and quality assurance, a management structure has been defined.

Figure 1. General FIDE structure. Figure 1 shows how the overall FIDE structure integrates within the Spanish Administration hierarchy. In fact it is only a proposal, but according to it, FIDE would be a subcommittee within the Technical Commission for the Quality in Construction. The inner structure of the FIDE management bodies is composed of three layers. At the upper layer is the Steering Committee which is in charge of the strategic direction. Under this group is the Technical Committee which deals with all the technical issues related to the model development. Finally, at the bottom level, there are the working groups which are made up ad-hoc for the development of concrete projects. The Steering Committee is in charge of setting the main strategic lines of the FIDE initiative. Amognst their responsibilities are: approving the inclusion of new extension projects under the FIDE denomination. For these decisions, they will have the support of a group of technical experts: the Technical Committee members. Finally they have the responsibility to take the decisions about activities funding. Furthermore, the Steering Committee holds the representation of the FIDE activities within the framework of the Spanish Administration. The Technical Committee is responsible for the quality management of the FIDE data model. Its members must take care of the different implementations and coordinate the different work groups which are developing areas of the model. To this end, they must watch and assess the different implementations and extensions of the model, and provide

eWork and eBusisness in architecture, engineering and construction

226

the developers with their advice and support. This Committee defines the technical framework for the adequate development of activities under the FIDE initiative. Thus providing a controlled environment for the developers, which is the first step towards the quality assurance of the model. These activities include the specification of issues such as the development methodology and tools, as well as infrastructure and common information resources.

Figure 2. Work groups structure. The Technical Committee is also the responsible for the representation and defence of the FIDE initiative before other organizations or technical work groups. This includes official standardization organizations (AENOR, CEN, ISO) and national or international consortiums (IAI, OASIS, …) Work Groups can be made up ad-hoc for solving specific objectives within the model. They should make an agreement with the Technical Committee to decide the suitability of their objectives and their work plan within the FIDE model long-term objectives. The work groups structure is shown in Figure 2. As soon as the Technical Committee has approved an extension proposal, the work group will be allowed to use common information resources from within FIDE (templates, technology, etc), and provide their results to be integrated into the general model.

Fide: Xml-based data model

227

3.3 Maintenance and extension procedures A major concern in the development of the FIDE data model is the quality assurance. The need for a model like this one is obvious in the sector and as it has been justified above its use will increase the efficiency in the construction processes as well as the quality of the obtained results. However, in spite of this positive breeding ground, there exists the high risk of developing an useless model. This may happen if the quality issue is not given the adequate consideration. For this reason, the model quality assurance will be one of the major issues in the development and the assessment of contributions. In this line, one very important issue for the model quality assurance is its usability, this is obtained by assuring the following features: it must be understandable for the developers in charge of its implementation. This applies mainly to software application developers but also to work groups dedicated to make an extension of the FIDE model in some specific area. To this end, some basic norms will have to be followed, on the one hand related to naming and structure of the model and on the other hand a complete and well-done documentation of the model is essential. By following these guidelines, the result will be to obtain a more intelligible and reusable model as well as a higher level of implementation. Concerning the extensions of the FIDE model, the developers must follow a defined methodology. This methodology describes the process for the extension proposals fulfilment and presentation. Thus, a set of steps has been defined in order to facilitate the task for the proposer groups and the Technical Committee. To sum up, a proposal should include the following elements: – Description of the utility of the extension. – Integration of the extension within the general FIDE model and other standard reference models. – Project development plan. This way, the potential developers can communicate their idea in a homogeneous way, and the Technical Committee has some objective parameters to assess the different proposals and evaluate their feasibility. The methodology also includes the description of the steps to be followed in the development of new models, or sub-models. The process must be done in four steps: – Identification of the sub-model field. The developer group must identify the field of study where they are going to work, that sets the framework where the concepts to be modelled are fitted. – Process model definition. A process model must be defined, preferably using IDEFO representation, which includes the processes under study in the modelling exercise. The process model must include the exchanged documents as well as the participating agents. On the other hand there also exists the possibility for the developers to identify the processes on a reference standard process model instead of developing a new one. – Integration within the global model. A study must be performed in order to identify which parts of the global model are going to be affected by the submodel to be developed. – Model development. Finally, after the Technical Committee approval, the work group will proceed to the actual model development. To that end, they will develop the parts

eWork and eBusisness in architecture, engineering and construction

228

not included in the global FIDE model. Subsequently, they will proceed to the integration of the sub-model within the global FIDE model. This development process will be performed following the technical indications and advice from the FIDE Technical Committee. 3.4 Technical issues As it has already been mentioned, one of the main objectives of the FIDE project, and thus of the consequent FIDE data model, is the compatibility with similar international initiatives. More concretely, the actual reference for the development of the model has been the IFC model. The IFC standard (Industry Foundation Classes) is a standard promoted from the construction industry by means of the IAI (International Alliance for Interoperability). IAI is an association of organizations involving engineers, architects, constructors, national administrations, etc. It arised in 1995 aiming at fostering a product data model for the data exchange amongst different applications within the construction sector. After some years, ISO has approved its last release, IFC2X, as an ISO Publicly Available Specification (ISO/PAS 16739), thus making IFC into an ISO standard. One of the main decisions for the consortium was the choice of the method to represent the model. In this line there are several possibilities, namely UML diagrams, Express schemas, XML schemas. A deep study was performed evaluating pros and cons of each of them. Eventually the decision was to use XML schemas [3,4]. This decision has been strongly meditated as it has some advantages and some disadvantages. Anyway, after this detailed analysis, there was a clear decision to use this meta-language for the model representation. The reasons for this decision are stated below: – XML meta-language is the de facto standard for the data exchange in the network. On the other hand, one of the main objectives in the development of the FIDE model is to facilitate the B2A (business to Administration) to improve the relation between the Administration and the industry. Providing the tools for procedures such as electronic delivery of documentation, eTendering, etc. This way, by using XML in the development of the model, we are moving forward to the facilitation of these B2A procedures. – There exists a very high level of use of XML at the International level, this will facilitate the spread of the model.

– At the moment there are a lot of available software tools to work with XML. On the one hand there are plenty of tools for the manipulation (edition, visualization, creation) of XML files. On the other hand there also are a lot of development tools such as programming libraries. The proliferation of such tools does make easier the adoption in the industry of the XML structures. – The most extended international standards in this sector, ISO STEP and IAIIFC, evolve or already support XML [5]. – The existence of programming libraries and SDK (Software Development Kits) facilitates the task to developers. This is a key issue, because it promotes the faster development of applications, and as a consequence a bigger expansion of the model.

Fide: Xml-based data model

229

The consortium suggests a set of tools in order to facilitate the developers’ task. Namely, these tools and methods are IDEFO for the process models, UML for the conceptual data models, and XML for the physical data model. 4 FIDE MODEL 4.1 Model framework As it has been introduced, the main aim of the current project was not the development of a complete model. More precisely, the intention was to establish the mechanisms for a self-maintenance and development of the model. These mechanisms have been described in the previous section. In this section a sample of the developed model will be shown, just to give the flavour of the model under development. This sample sub-model has been developed in the area of quality management in the construction sector. This is a very important issue in the sector and has gained a lot of attention in the latest years. The main aim is to achieve better quality in the final product by means of controlling the whole life-cycle of the construction process. In the case of the Spanish situation the quality control procedures are mainly driven by the Administration. Some of the mechanisms they use have been deeply studied within the FIDE framework, namely a control book, quality profile, building book and material test. Most of the information to make up the model has been extracted from the analysis of this documentation. Furthermore the overlapping amongst them has been accurately analysed. 4.2 Reference model: IFC The FIDE consortium has decided to take the IFC model from IAI as the reference model. Specifically the latest XML version for the release IFC2x 2nd Edition: ifcXML2. FIDE data model does not include the whole ifcXML2 model. It only plans to pick the needed entities from IFC and then to complete the entities according to the specific needs. In some cases these entities must be extended to fulfil the needs. One of the main concerns is to keep the compatibility with the standard initiative in order to get an open and usable data model.

eWork and eBusisness in architecture, engineering and construction

230

Figure 3. FIDE general structure.

4.3 FIDE model sample The approach selected for the FIDE model architecture is a layered modular solution. This structure is defined in the following lines: • Each entity represents a concept from the real world. These elements are represented through XML schemas, composed by an identification, a set of attributes and some relations with other elements. • The related elements are put together to make up conceptual groups. These groups are called clusters. • The whole structure is a layered structure: – Each layer contains the entities that several entities from an upper layer do use. This way the model avoids duplicity of re-used elements in the model. – The lower level is called kernel. It contains the most basic and re-used elements. In the sample of model here shown, the modelling target has been a descriptor for the building, focused on the administrative identifiers, and the general structure. The features that describe the model and the work done are stated below . – The modelled element has been a descriptor for the building. It is a common element in the documentation related to quality management in construction. It appears in the design, construction and facility management phases. – The building descriptor contains the set of data that describe a building from the administrative and formal point of view. – In order to make use of the defined methodology, the element was studied from different points of view and several sub-models were obtained.

Fide: Xml-based data model

231

Figure 4. Building descriptor schema. Finally these sub-models were integrated to obtain just one common model for the building descriptor Figure 4 shows a sample of the XML schema that has been developed within FIDE. In concrete it shows part of model for the building descriptor. 5 CONCLUSIONS AND FURTHER WORK Following are shown the most important conclusions: – It has been checked that the model tends to organise itself following the layered approach presented above. This happens in a natural way as new elements are analysed and included within the model. New elements share data sets with existing elements, these data have to be included in the lower layers for reuse. – The development of diiferent parts of the model separately for its latter integration has shown to be a right way of working. This has demonstrated the viability of the defined strategy for the long term. – IFC model is very flexible and complete. However this makes it very complex and ambiguous to some extent. To reduce the ambiguity is one of the main concerns in the FIDE model. Thus avoiding problems between different software vendors implementation of the same model.

eWork and eBusisness in architecture, engineering and construction

232

– We have confirmed that the main modelling problems to be solved had already been faced in the IFC model. This validates the modelling strategy defined within the FIDE model. – Despite the big scope of the IFC model, the absence of some important elements and attributes for the Spanish construction sector has been detected. These elements are essential for the utility of the model in the Spanish national level. That confirms the need for extension of some of its features. – The XML available tools have facilitated the creation and understanding of the model as well as the documentation generation. This is so thanks to its clarity in representation, and the big amount of different tools The nearest further work consists of the continuity in the development of the model, firstly to complete the quality management area and then fulfilling new areas of interest in the construction sector. The Administration has shown its determination and deep interest in the FIDE project by assuring the development for several years on, so the model will keep evolving along the coming years. Apart from this, and as important as it or even more, the very next target will be the promotion and dissemination of the results obtained so far. Furthermore, the emphasis will be set in the development of software applications in the Spanish sector. REFERENCES [1] http://www.codigotecnico.org/ [2] http://www.iai-international.org/ [3] “XML Schema Part 1: Structures Second Edition”, W3C Proposed Edited Recommendation, March 2004. [4] “XML Schema Part 2: Datatypes”, W3C Recommendation, May 2001. [5] “Options for the IAI regarding XML”, Thomas Liebich.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

A framework for concurrent structure analysis in building industry A.Niggl, R.Romberg & E.Rank Lehrstuhlfür Bauinformatik, Technische Universität München, Germany R.-P.Mundani & H.-J.Bungartz IPVS, Abteilung Simulation groβer Systeme, Universität Stuttgart, Germany ABSTRACT: In this paper, a software-framework will be presented, which helps to support the concurrent work of multiple planners in the construction industry. Basis of this work is a strictly volume-oriented building model. This model is stored in a central database, which supports the cooperative work by using object-based ‘check-in’, ‘check-out’ and ‘locking’ mechanism. Furthermore a decomposition algorithm will be presented, which automatically derives a hexahedral mesh for a finite element computation from this central building model.

1 INTRODUCTION The efficient and accurate exchange of data is an important basis for a successful cooperative work in the field of computer-supported planning and design in building industry. This fact not only holds for the exchange inside a homogenous group of planners, it is also important for the data-transfer between planning processes within different working-domains. In this paper, a software-framework will be presented, where a central volumeoriented geometric model is considered as a basis to support the cooperative work and the integration of different planning-processes. The central data set is thereby given by an explicit geometric B-Rep (Boundary-Representation) model associated with semantic product data attributes, which is originally derived from an IFC product model. Using a classical client-server structure, the building model is provided centrally and can be accessed by different planners. The concurrent access to the database is organized similar to classical software-management-systems, where single entities can be ‘checked out’, locally modified and ‘checked in’ by the user. To ensure geometric consistency of the common data model, an octree-based algorithm is applied, which was developed in this project. The geometric building model is the starting point for various subsequent tasks in the planning process. For the structural analysis, we present an automatic generation of a volume-oriented finite element mesh, consisting of solid hexahedral elements. In addition to the finite element analysis, an indoor air flow simulation was also connected to the

eWork and eBusisness in architecture, engineering and construction

234

framework in an other project (v. Treeck et al. 2004). Figure 1 shows a schematic view of the framework. The outline of this paper is as follows: In the next section, the software-structure and techniques used inthis work will be presented. Then in Section 3 the automatic derivation of the hexahedral finite element mesh from the architectural model will be described in detail. Finally, in Section 4 the cooperative work of two planners will be demonstrated in an example

Figure 1. Schematic view of the framework: an IFC-model is converted into a geometric B-Rep model, which is saved in a central database; different clients can access in parallel the central data; a finite element model can be derived and analyzed automatically.

A framework for concurrent structure

235

2 A VOLUME ORIENTED GEOMETRIC MODEL 2.1 From IFC to an explicit geometric model In this project, a commonly shared geometric model is used as a basis for various tasks in the planning and simulation process. The geometric data of a building model given by the IFC-standard (IAI 2003) is usually not directly adequate for a numerical simulation, as it only describes the topology and the mutual connections of different structural components. For example, the geometry of a wall is described by a 2D profile together with an extrusion direction or a window is given by its relative position to an ‘anchor point’. But for the automatic derivation of subsequent simulation models, for example the generation of a finite element mesh, we need an explicit description of the geometry. Thus, we use the geometric modeller ACIS (Spatial 2004) to create a geometric model from the IFC-product model, where each construction unit is described by a single B-Rep object. The IFC data is accessed by using the Eurostep IFC-Toolbox (Eurostep 2000), which is an object oriented C++ implementation of the IFC scheme representation and which provides interface functionalities to access and manage instances of the product model. The semantic data contained in the IFC object model is added as attributes to the B-Rep entities und is saved parallel to the geometric data in an additional database. 2.2 Organization of the concurrent access The technical basis of our cooperative workspace is a classical client-server architecture. In order to ensure consistency of the central data model, the concurrent access by the clients is being controlled by an intermediary management layer. Similar to well known software-management systems, like CVS (concurrent version system), the server provides methods for downloading, managing and uploading data. The smallest organizational entity in the exchange is thereby one single B-Rep object. Using an octreebased algorithm, the management layer ensures geometric consistency of the internal data model. In order to share information among the concurrently working planners, notification services were developed in this project. The user can activate a locally working software module, which connects to the server and informs him about modifications in the central data model caused by other planners. In a configuration menu, the user can choose among different notification levels. He has also the possibility to reduce the number of objects, he wants to be informed about, to a subset of the complete model. During runtime and depending on the type of useraccess, a single object on the server can remain in one of three different states: clean, shared and locked. An object is clean, if no client has accessed this object for modification. It is in state shared, if at least one user has accessed the object in read- and/or write-mode and it is in state locked, if just one client has claimed exclusive write permissions for an object. The operational procedure in the user-side workspace will be demonstrated in an example in the last section in detail. Thereby, one thing is always the same: In order to

eWork and eBusisness in architecture, engineering and construction

236

upload (check-in) modified or new objects to the central database, the user has to checkout the selected objects first. Based on the internal states mentioned before, for each object, the user can choose among three possible modes of access: • Read-only: in this mode, a modification by the user is not allowed. However, the user will be registered on the server and has the ability to activate the notification service for the selected object. • Read-write: the user gets read and write access for the data, which allows him to check in modified objects to the server. Modification by others is also possible. • Exclusive-write (lock): the user gets exclusive write access to the object. Modification by others is not allowed. Only in case of read-write mode, a concurrent access of objects is possible. In this case, each upload by a user will overwrite the current version in the central database. To avoid confusion, the notification service may help, so that the user can stay informed about the actual state and can react accordingly. This makes sense especially in cases, where one user (e.g. a designer) changes the geometry of an object while an other user (e.g. a structural engineer) only wants to modify some attributes like loads or material. In such cases, an exclusive lock by one user would only hamper the work of the other. In cases where one wants to prohibit concurrent access by others completely, e.g. when substantial modifications must be applied, exclusive-write access should be used instead. After modifications in the local workspace are finished, the user will check in his object to the central database. Each upload of a modified or new building object will thereby initiate a consistency check on the server, according to the method which will be explained in the next sub-section. In the case of geometric collisions or insufficient access rights, the upload will be rejected and the user will be informed about the problem. 2.3 Consistency check Before any consistency check can be performed, volume-oriented models have to be derived from the respective surface-oriented ones. In (Mundani et al. 2003) we presented an algorithm for the generation of octrees by intersecting half-spaces, allowing us a fast and efficient derivation both in real time and on-the-fly. Applying the Boolean operator ‘intersection’ on two octrees, collisions of type ‘overlap’ and ‘gap’ can easily be detected. Whenever two voxels—volume elements—of two arbitrary octrees claim for the same space an overlap occurred and the algorithm can stop at this point. Depending on the maximum depth of recursion dmax overlaps up to h=1/2 dmax on the finest resolution level can be found. In this case, the check-in of modified parts is rejected by the server. When no overlap could be detected, the two parts or the two volume-oriented models, respectively, are either lying perfectly together side by side or are disjoint. In the latter case, a gap among these two parts exists; only gaps of certain sizes are from further interest. Therefore, the algorithm has to determine the maximum depth deff reached during the intersection calculation, not to confuse with the maximum depth of recursion dmax. By specifying dgap, the maximum gap size, only in case of dgap≤deff< dmax a gap has been

A framework for concurrent structure

237

detected. The corresponding part is allowed to be checked in but further user feedback is necessary, because most gaps unintentionally occur due to design or round-off errors. 3 STRUCTURAL ANALYSIS 3.1 A volume oriented flnite element approach In contrast to the classical way in finite element analysis using dimensionally reduced models (e.g. 2D-plates, shells or beams), in this project the structural analysis is performed in a fully volume-oriented approach. The complete structure is discretized consistently with solid hexahedral elements and the computation is carried out by using higher order elements of the so-called p-version of the finite element method (Szabó et al. 1991, Szabó et al. 2003, Düster et al. 2003). This approach has some important advantages: • The automatic derivation of a finite element model from the original (product-) model is simpler, if this transition can be done consistently in the same volume-oriented way. • The possibility of such an automatic model derivation releases the engineer from a ‘manual’ reconstruction of various numerical systems. • Using solid finite elements, possible three-dimensional stress conditions can be resolved. • There is no need for coupling different dimensionally reduced mechanical models. 3.2 Automatic derivation of the flnite element mesh An important basis of our consistent volume-oriented approach is the automatic derivation of the finite element model (Romberg et al. 2004). The basic idea of the underlying algorithm is to decompose the given geometric building model into a set of simpler geometric objects and decompose each of these objects again into hexahedral elements. To ensure compatibility (i.e. no hanging nodes) of the final mesh, the whole procedure is carried out in a set of steps, which are mainly used to find a common discretization at the interface of different entities. It should be mentioned that this approach does not aim at meshing general spatial volume-structures but is capable of decomposing a typical building model, which usually consists of objects like plates, beams, columns and slabs. 3.2.1 Connection model decomposition As a first step in the process of creating a hexahedral mesh, the given geometric building model is decomposed into a so-called connection model using boolean operations. Figures 2-4 illustrate the basic idea. Starting from the set of building models Mb, these elements are partitioned into a set of coupling objects Mk and a set of difference objects Md. The set of coupling objects Mk are then again recursively decomposed into coupling objects of different levels (Mkl … Mki).

eWork and eBusisness in architecture, engineering and construction

238

Each coupling and difference object is itself a closed B-Rep body being described by nodes, edges and faces. After decomposition, the intersection between difference objects or coupling objects of the same level is given in points and edges only, whereas adjacent difference and coupling objects intersect in faces, edges and nodes. After applying this decomposition algorithm, the resulting elements have some important characteristics with respect to the following steps in finite element

Figure 2. Initial configuration Mb with three objects.

Figure 3. Creation of connection objects (Mkl, Mk2) using boolean operations.

A framework for concurrent structure

239

Figure 4. Decomposed connection model Mc. mesh generation: Each coupling object Mk possesses hexahedral structure, thus, it can be easily partitioned into smaller elements, whereas each difference object Md is ‘plate shaped’ and can be assumed to be obtained from sweeping a two-dimensional polygonal domain. 3.2.2 Generation of hexahedral finite elements The connection model shown in the previous section is the starting point for the automatic generation of hexahedral elements in the next step. Thereby we use either elementary three-dimensional meshing macros mainly applied to the coupling elements or, in case of the plate-like difference objects, hexahedral elements are obtained by creating a 2D quadrilateral mesh on the polynomial mid-face and sweeping this mesh to the third direction. Most crucial in meshing is yet the question of generation of compatible elements. For this, we apply a two-step approach. In a first run, a reasonably refined mesh for each (separate) difference object is defined. According to the different discretization on the boundaries of adjacent elements a compatible discretization must be determined. When this common discretization is found on the boundary,

eWork and eBusisness in architecture, engineering and construction

Figure 5. Original 3D volume model given by the CAD system.

Figure 6. Decomposed connection model.

240

A framework for concurrent structure

241

a new mesh is created on the difference objects in a second run, which is then compatible with its neighbours, i.e. the resulting mesh has no hanging nodes. 3.3 A complex example In this section, the process from the original geometric building model to the finite element results is demonstrated in an example of a realistic office building. The building is constructed by reinforced concrete and consists of two massive inlying building cores, six floor plates and supporting columns. It has dimensions of about 40×30 meters in the ground view. Figure 5 shows the geometric model. In Figure 6, the decomposed connection model can be seen, which was derived from the original model according to Section 3.2.1. One can see easily the connection elements on the top floor plate, created at the intersection of the inlying building cores and the plate.

Figure 7. Finite element mesh.

eWork and eBusisness in architecture, engineering and construction

242

Figure 8. Finite element results; plot of vertical displacements. Figure 7 shows the finite element mesh, derived from the connection model according to subsection 3.2.2. It consists of 8313 hexahedral elements. In Figures 8 and 9 the finite element results can be seen. First, in Figure 8, the displacement plot is depicted. Figure 9 shows mean stresses (v. Mises stress) in a zoomed detail. For the computation, vertical loads on the floorslabs and horizontal wind-loads were considered. The results were computed using the p-version of the finite element method with a polynomial degree of 3. This resulted in a computation with 269, 043 degrees of freedom, which took about 2 h of time on a Pentium IV with 1.7 GHz.

A framework for concurrent structure

243

Figure 9. Zoomed detail of stress plot (v. Mises stresses).

Figure 10. Complete model in workspace A.

eWork and eBusisness in architecture, engineering and construction

244

4 CONCURRENT WORK EXAMPLE In this section, the concurrent work in a group of multiple planners will be demonstrated in an example. The office building shown in the previous section is now modeled and stored in the central database, which was described in detail in Section 2.2 and 2.3. In this context the database is also referred to as ‘server’. Let us assume, that planner A (e.g. an architect) decides to carry out some modifications in the model. In a first step, he may request for an update in order to get the newest model version from the server (Fig. 10). Then, he checks out some objects with exclusive-write access in order to apply some modifications, e.g. move a column to another place (Figs. 11, 12). In the meantime, planner B (e.g. a structural engineer) has also checked out some other objects and changes load attributes (Fig. 13).

Figure 11. Check-out of selected items by planner A.

A framework for concurrent structure

245

Figure 12. Change of column by planner A.

Figure 13. Change of load attributes by planner B.

eWork and eBusisness in architecture, engineering and construction

246

Planner A has finished his work now. So, he selects the modified objects and tries to check them in to the server (Fig. 14). Unless any other user has locked one of the objects exclusively or the consistency check detects an intersection, the check-in is successful and the objects will be stored in the database and overwrite their current version there.

Figure 14. Check-in of modified column by planner A.

Figure 15. Local database agent informs planner B about the modified objects.

A framework for concurrent structure

247

This occurrence of objects checked in is now reported automatically to planner B, because he has activated his local notification agent with the order to listen for geometric modifications (Fig. 15). Technically, every check-in is thereby posted to a message queue on the server, where each message contains information about the type of modification (geometrically, only attributes, type of attribute…), the user, etc. This message queue can be read out by the remote, client-side notification agent, which prefilters the messages according to the user’s settings and sends a signal to the user. Back to planner B, the structural engineer, after updating his local workspace, he initiates a new finite element computation on basis of the modified model.

Figure 16. Resulting finite element mesh of the modified model. Again, the derivation of the finite element mesh and the computation is performed completely automatic and needs no further manual interaction by the user. Figure 16 shows the finite element of the modified model, where a complete line of columns was changed. 5 CONCLUSION We have presented an approach, which may help to support the co-operation between different planners in building construction. The concurrent work is organized, using a

eWork and eBusisness in architecture, engineering and construction

248

central database with its accessmanagement layer in combination with a consistency check and notification services. The automatic generation of a finite element mesh, based on a strictly volume oriented model, releases the engineer from manually transferring design models to the numerical simulation model. This helps to speed up the design process, especially in cases, when modifications and different design variants must be investigated. ACKNOWLEDGEMENT This research has been supported by the Deutsche Forschungsgemeinschaft (Priority program 1103, “Vernetzt kooperative Planungsprozesse im Konstruktiven Ingenieurbau”) to which the authors are grateful. REFERENCES Düster, A., Bröker, H. & Rank, E. 2001. The p-version of the finite element method for threedimensional thin-walled structures. International Journal for Numerical Methods in Engineering:52, 673–703. IAI, International Alliance for Interoperability 2003. IFC Release 2.x. Internet: http://www.iaiinternational.org/. Eurostep 2000. The IFC STEP Toolbox. Eurostep Group. Stockholm, Sweden. Internet: http://www.eurostep.com./ Mundani, R.-P., Bungartz, H.-J., Rank, E., Romberg, R. & Niggl, A. 2003. Efficient Algorithms for Octree-Based Geometric Modelling. Proceedings of the Ninth International Conference on Civil and Structural Engineering Computing, Topping, B. (ed.). Civil-Comp Press. Romberg, R., Niggl, A., v.Treeck, C. & Rank, E. 2004. Structural Analysis based on the Product Model Standard IFC. Proceedings of the 10th International Conference on Computing in Civil and Building Engineering (ICCCBE). Weimar, Germany. Spatial Corp. 2004. ACIS 3D Geometry-Modeller. Westminster. Colorado, USA. Internet: http://www.spatial.com./ Szabó, B.A. & Babuπka, I. 1991. Finite element analysis. John Wiley & Sons Ltd., New York, USA. Szabó, B.A., Düster, A. & Rank, E. 2003. The p-version of the finite element method. Accepted for publication in Stein, E., de Borst, R. & Hughes, T.J.R. (ed.), Encyclopedia of Computational Mechanics, John Wiley & Sons Ltd. NewYork,USA. v.Treeck, C. & Rank, E. 2004. Analysis of Building Structure and Topology Based on Graph Theory. Proceedings of the 10th International Conference on Computing in Civil and Building Engineering (ICCCBE). Weimar, Germany.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

IFC supported distributed, dynamic & extensible construction products information models M.Nour & K.Beucke Bauhaus University, Weimar, Germany ABSTRACT: This paper reports ongoing research work on a new approach of using electronic product libraries based on the concept of Object Information Packs. This approach is based on top of the IFC model and the GTIN (Global Trade Item Number) concept. The paper presents a complete specification of the OIP concept and a perspective of some of its implementation scenarios. The main objective is establishing a link between Objects in the IFC model from one side and their technical and commercial attributes at the manufacturer and supplier from the other side. This should enable multidisciplinary cross-industrial lifecycle information to be captured by any IFC compatible application. The paper discusses several scenarios for the implementation of the OIP concept together with a simple IFC example.

1 INTRODUCTION 1.1 Building information models The construction industry is working very hard to bridge the gap between its islands of automation. The efforts have taken many forms e.g. neutral file formats, APIs (Application Programming Interfaces) and BIMs (Building Information Models). The latter is expected to provide a means for sharing and exchanging of information. The first intention towards a Building Information Model started in the mid-1970s by independent efforts to develop a number of integrated systems, based on a single model that supports various applications e.g. OXSYS CAD and CEDAR and HARNESS hospital design systems in England (Eastman 1999). Although it is now more than thirty years later, the BIM approach is still not a common practice in the AEC industry. One major problem facing BIMs is the absence of the responsibility for modeling the construction product and material in a multidisciplinary cross industrial level of abstraction. It is obvious that architects working on a project that contains thousands of elements would not have the resources to create a model for each element. They would be most probably paid for the production of printed drawings and documents rather than models. It is not only the architect; we can imagine the problem for all the involved disciplines. The problem is even worse when we consider that these models could be prqject specific and cannot be used in a product library for similar projects at other organizations. Most probably this approach would go beyond any return on investment employed.

eWork and eBusisness in architecture, engineering and construction

250

1.2 Product catalogues The majority of manufacturers, product information brokers and portal websites are offering online ‘electronic paper’ versions of the old catalogues using convenient presentation formats such as PDF and HTML (Augenbroe 1998). Some Internet portal websites have developed their services to offer online product models. Although this is considered a big step towards the process of automation of a building information models, it still has its shortcomings and problems that need to be resolved. One of the problems is that this approach does not seem to have obvious influence on the traditional paper based catalogue selection process (‘off-the-shelf’ products). Moreover, there is little evidence of efforts related to studying how designers search for products, evaluate them and make their selection decision (Shailesh et al 2003). On the other side of the value chain, it is not clear how can the required multidisciplinary cross industrial information from the manufacturer and supplier can be captured online, together with tools that assist queries and decision making processes rather than decision taking. A major problem with BIMs is that they become of little use, when the information provided by the model is insufficient or obsolete e.g. (price or availability of a product) or when a certain application requires a piece of information that can not be supplied by the model. More often than not arises the need in the AEC industry for more information or updates of information about a product. For example, it is argued by researchers like (Laitinen 1998) that a cost estimate for a prqject is repeated seven times in average. Furthermore, Value Engineering activities and cost optimization necessitates carrying out different changes and substitutions of products and materials to the design to reach a satisfying decision. In addition, the need for multidisciplinary life cycle information makes it inevitable to need more up to date information about a certain product e.g. the FM (Facilities Management) discipline is more often than not in need for maintenance information about a certain product, when the rest of the AEC disciplines have already left the project. 1.3 The proposed solution In the coming section, the paper explains a new approach that is envisaged to help automating the development of a building information model. The author suggests that the information model should be produced as a part of the construction product itself. This information model grows with the development of the product e.g. the manufacturer would be responsible for the technical properties and later the supplier or wholesaler would be responsible for the dynamic commercial aspects, when it is on sale in the market. The aggregation of this type of multidisciplinary and cross industrial information is represented and made available online through the “OIP” (Object Information Packs).

IFC supported distributed, dynamic & extensible

251

2 OIP SPECIFICATIONS 2.1 Definition OIP Stands for Object Information Packs. An OIP is a multidisciplinary cross industrial continually updated pack of information about a construction product or a service, upon which there is a need to retrieve predefined information at anypoint in the value chain. This information pack acts as a base unit of information supply to BIMs (Building Information Models) throughout the building’s overall lifecycle. 2.2 Format It is produced in a software independent neutral format like ISO 10303 p-21 STEP or XML, i.e. it enables the transfer of structured data, by agreed message standards from one party (computer) to another by electronic means with minimum human intervention, i.e. machine-to-machine language. 2.3 Producer The OIP has to represent both technical and commercial information of the construction product. This information is usually produced jointly between the manufacturer from one side and the supplier, retailer, importer or wholesaler from the other side. This means that the OIP is finally determined at the point of aggregation of both types of information. This aggregation or double composition ensures the uniqueness of the OIP as an identifier of the construction product and enables its dynamic properties, i.e. commercial properties can be continually updated and the technical properties can be extended. The final OIP identifier is finally issued by the organization that owns the brand name of the product regardless where, and by whom it has been manufactured. 2.4 Genesis The OIP is designed to be built on top of EAN (Einheitliche Artikel Nummer), which is a type of a GTIN system (Global Trade Item Number). It inherits its well-established norms for global trading and adds further restrictions and capabilities to suit the characteristics of the construction industry. The OIP can be mapped (converted) to EAN, whenever needed. 2.4.1 OIP versus EAN OIP is a construction oriented global lifecycle identifier that links cross industrial multidisciplinary information. It is mainly designed to suit the characteristics of the various procurement systems of the construction industry. On the other hand EAN is considered to be a product item reference and a check digit. The EAN is a pointer to a

eWork and eBusisness in architecture, engineering and construction

252

database (at the EAN local organisation). However, this database does not include information more than the producer’s name and contact details. Both OIP and EAN have a check digit for the validity of the identifier. The OIP goes beyond this by adding an extra validity check, that checks if the product fits into the design or not, e.g. if an OIP of a 1.2 m door is linked to an opening of 0.9 m width in the Building Information Model, this conflict should be detected and the OIP rejected. OIP provides dynamic lifecycle information. This means that information can be continually updated. Updates and versioning are two faces of the same coin. Therefore, OIP allows for versioning. This enables dynamic properties of the product like price and availability to be continually updated. At the meantime, there are different priorities and objectives standing behind the EAN and OIP. Some properties are of greater relevance to commercial trade uses than to construction uses and vice versa, e.g. tracking and tracing of logistical units and returnable assets is of a great value for trading. This could still be used in construction for determining things like the percentage of completion of works and delivery of products to construction sites and so forth. Although it seems of no use to stick a barcode on a beam on a construction site, where it will most probably be lost, it still can be useful to read (scan) the barcode from printed product catalogues and link the OIPs to the BIM in the design phase. Moreover, the use of new technologies like: programmable mobile phones with scanners and cameras in future may enhance the effect of an OIP Barcode for on-site use. 2.5 Degree of granularity One of the problems facing OIPs is the degree of nesting of elements. In other words, to what extend would the OIP reference other OIPs of the constituent components. In some cases like in electromechanical equipment, we can not determine at which level should the OIP referencing stop. Is it to the screw level, or to the material of the screw. … To put an end to this problem, OIP is designed to reference other construction products and materials only as a maximum detailing level e.g. a concrete brick may reference cement, sand and gravel as leaf elements. Other sophisticated construction elements like electromechanical equipment and so forth are not further referencing their components. However, there is another ISO Standard (ISO 13584 Plib), which is a STEP-EXPRESS based standard that is designed specially for this purpose and it is technically feasible to be referenced from OIPs whenever needed. 2.6 Limitations OIPs are not aimed by any means to solve the taxonomy problems of the construction products’ properties. Thus, the product properties are limited to the attributes and published property sets of the IFC 2x model (ISO PAS 16793 (lAIntern 2003)). This enables the exchange of multidisciplinary cross industrial technical properties between parties beyond national borders without any mis-understanding due to differences in languages, classification systems or organisational cultures. However, the commercial properties will remain subject to international trading conventions and standards.

IFC supported distributed, dynamic & extensible

253

2.7 An OIP organization An important task contributing to the success of OIPs is the responsibility of the management of the OIPs themselves. Things such as numbering and keeping

Figure 2–1. The structure of the OIP. records of technical properties of products have to be managed by an international nonaligned organization. Therefore, the main mission statement of the OIP organisation is the allocation of the OIP technical section and keeping records of technical information about products in an online database, where it can be accessed at any time by any user. Furthermore, it may optionally in certain cases give a reference to the brand name holder, where the dynamic commercial properties of the product reside. 2.8 The design of the OIP Figure (2–1) shows that the OIP consists of two main parts; the technical part and the commercial part. Both of them compose the OIP and formulate it as a global unique identifier for a construction product, service or material. A product under different brand names can have one or more OIPs with the same common technical part, but with various commercial parts. This enables the OIP to represent commercial properties supplied by the brand name holder in addition to the technical properties provided by the manufacturer. The technical part is relatively static as the technical properties do not change but can be extended. On the contrary the commercial aspects like price, availability and discounts can change dynamically. 2.9 The formulation of the OIP Figure (2–2) shows how an OIP is formulated and how it can reference the OIPs of its constituents. It also shows the combination between the technical and commercial parts of the OIP Furthermore, it shows the entire relation between the end-user, supplier, manufacturer and the OIP organisation. It is an example of a simple brick that consists of cement, sand and gravel. The brick itself has technical properties provided by its manufacturer. The OIP of the brick further references the technical parts of the OIPs of its constituents. As a general rule, the OIP is only complete, when its both components (the technical and commercial parts) are present. The manufacturers or the suppliers have

eWork and eBusisness in architecture, engineering and construction

254

to register the technical properties according to the IFC model and its published property sets at the OIP Standard Organisations. At the time of conducting this research work, the EAN keeps in its database only some basic information about the brand name holder, like contact details. However, it does not offer any commercial properties that belong to any product. Such properties like availability, price and discounts are best managed by the commercial organisation itself. Therefore, the OIP organisation can exceptionally include a link to the brand name holder or commercial organisation to overcome this shortage of the EAN system. 2.10 The OIP identifier As it is earlier mentioned, the OIP is built on top of EAN. Hence, the commercial aspects are encoded in the EAN. However, the EAN item number will be extended to include a versioning system that enables the dynamic management of commercial information. The technical part of the OIP is a reference to a pack of information residing at the OIP organization. This pack of information contains information about the product according to the attributes and published property sets of the IFC model. It may also contain

Figure 2-2. The formulation of the OIP.

IFC supported distributed, dynamic & extensible

255

Figure 2-3. EAN and OIP structures. optional references to other OIP(s) of leaf elements that form the main product by their aggregation, e.g. cement for the brick or reinforced concrete. 3 OIP IMPLEMENTATION This part of the paper describes the implementation of the OIP concept in real life scenarios, together with a simple example using a limited number of product attributes to enable the reader to follow the logic behind the OIP idea. Before the example is presented, the abstract concept of the OIP is clarified. 3.1 The basic concept The whole idea can be simplified as a mapping and merging from two source models (S1 and S2) to a target model (T1). In Figure (3-1) S1 represents the OIP organization, where all multidisciplinary technical information resides. S2 represents the supplier or brand name holder of the product; where all the commercial properties reside. T1 represents the client or the user, where it is envisaged to be a group of AEC applications built on top of the IFC model. There are many different scenarios where the OIP concept could be implemented. However, this paper focuses on two main scenarios. First is the traditional way of using paper based catalogues or CD-ROMs. The OIP reference (identifier) can be instantiated by the CAD package or by adhoc software. Lifecycle information can then be retrieve using the OIP identifier and the required data can be mapped and merged to the IFC model at the client’s side (through a distributed network application). The second scenario is a more complex one. It depends on the capture of the required object parameters from the CAD/IFC model. These parameters are

eWork and eBusisness in architecture, engineering and construction

256

Figure 3-1. The OIP implementation. used to carry out a parametric search (attribute based) versus a descriptive search in the first scenario. This can be achieved by using SQL, bcXML(Tolaman et al), or EXPRESSX. The result of this search is a list of products that satisfy the search parameters. This list can be sorted according to the value of any selection attribute, e.g. price, sound absorption coefficient, fire resistance and so forth. A step forward in this approach would be the selection and appraisal process i.e. decision making versus taking. This can be done by conducting a virtual experiment under simulated real conditions, where the product will be performing (i.e. providing full context conditions). The experiment is repeated several times on the short listed products. Each time a product from the candidate products is substituted, tested and ranked according to the performance in the virtual experiment. By using this approach the user can determine a set of weighted performance indicators that represent the full context in which the product would be used. This coincides to a great extend with the principals of TQM (Total Quality Management); which is quality of performance rather than specifications (Nelson 1996). Any need for extra or up to date information should be reached through the OIP unique identifier. 3.1.1 Example By looking at a simple example for a door (IfcDoor), a door is selected according to the first scenario from an electronic catalogue from a portal web site (Figure 3-2). It is transferred through a drag and drop environment to the CAD application, where the OIP is instantiated to the door’s Tag in the IFC attributes (Figure 3-3). The door in the IFC

IFC supported distributed, dynamic & extensible

257

model consists of two main parts: the Lining and the panel (Figure 3-4). All the attributes of the door and its property sets can

Figure 3-2. Selection of a door from a portal. be reached through the OIP. The IFC published property sets of the door include things like the operation direction, overall size, operation properties (swing), material, panel and lining detailed properties, door common properties like: Infiltration, Thermal Transmittance, Fire, Security and Acoustic Ratings and so forth. These properties might be needed in later design or facility management stages by different AEC disciplines. Access to this information should be enabled through the OIP. If at any time the need for more information by any discipline arises, the product OIP can be accessed and the property is selected and merged to the IFC model at the client side. If the product needs to be changed for any reason, the same parameters could be used to conduct a new parametric search. This can also be done as a result of a commercial property change e.g. price or availability updates. If the product needs to be substituted with another product then a new OIP unique identifier substitutes the old one and so forth.

eWork and eBusisness in architecture, engineering and construction

Figure 3-3. The instantiation of the OIP in CAD.

Figure 3-4. IfcDoor panel and lining.

258

IFC supported distributed, dynamic & extensible

259

4 CONCLUSION This paper has introduced a new concept for the automation of the process of establishing a Building Information Model. This concept is called OIP. It depends on the IFC platform specification (ISO/PAS 16739) and EAN for the transfer, merging and mapping of technical and commercial data of the construction product. This mechanism enables the continuous up to date distributed communication between product models and their attributes, which reside by the manufacturer or supplier. This approach is envisaged to satisfy the need of information by the AEC disciplines during the product’s overall life cycle. Such strong standardization concepts do have their impacts on creativity of the design process. Researchers like (Howard 2001) argue that such standardization concepts limit the freedom of design as the alphabet limits literary expressions. On the other hand, every design is a redesign, and by applying this concept, we could foresee the window of opportunities that such a new concept can open. However, it may also have dramatic impacts on procurement of construction products and the process of automation of generation of documents i.e. it may enhance all the benefits of the Building Information Model and simulation applications. Finally, it should be mentioned that this research work did not try to tackle the taxonomy, languages, cross-organizational and cultural differences of the construction product attributes and properties. It adhered to the attributes and published property sets that are defined and published by the IAI in the IFC2x documentation. At the mean time, queries can also be conducted using SQL, EXPRESS-X, bcXML and so forth. REFERENCES Augenbroe, Godfried. 1998. Building Product Information Technology, White Paper. Atlanta: Georgia Institute of Technology. Available from http://www.arch.gatech.edu/crc/ProductInfo/ EAN 2004. The Global Language of Business, EAN International. Available from http://www.eanint.org/ Eastman, C.M. 1999. Building Product Models: Computer Environments Supporting Design and Construction, CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, Florida 33431, USA. ISBN 0-8493-0295-5. Howard, R. 2001. Classification of Building Information-European & IT systems. In Construction Information Technology, International conference: IT in Construction in Africa, pp. 9–1 to 9– 14. CSIR, Building and Construction Technology. IAIntern 2003 IAI-Industrie Allianz für Interoperabilität, Nr. 1/03, Januar 2003. pp. 7. ISO 10303-11 EXPRESS 1994. ‘Industrial automation systems and integration—Product data representation and exchange—part 11: Description methods: The EXPRESS language reference manual. ISO 10303-21 STEP 2002. ‘Industrial automation systems and integration—Product data representation and exchange—part 21: Implementation methods: Clear text encoding for exchange structure. Laitinen, J. 1998. Model Based Construction Process Management. PhD Thesis, Royal Institute of Technology, Stockholm, Sweden. Nelson, Charles 1996. TQM and ISO 9000 for Architects and Designers, McGraw-Hill.

eWork and eBusisness in architecture, engineering and construction

260

Shailesh, J. and Augenbroe, G. 2003. A methodology for supporting product selection from ecatalogues Journal of Information Technology in Construction, Vol. 8 (2003), pp. 383. Tolaman, F.Rees, R. & Böhms, M. 2002. Building and Construction Mark-up language (bcXML): The C2B/ B2C Scenario. Delft University of Technology, Netherlands. Workman, Brad. 2003. BIM (Building Information Model): “Does the Building Industry Really Need to Start Over?” A response from Bentley to Autodesk’s BIM proposal for the future.”, Bentley.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Product definition in collaborative building design and manufacturing environment H.Oumeziane & J.C.Bocquet Ecole Centmle Paris, Châtenay-Malabry, France P.Deshayes Ecole Centrale Lille, Lille, France ABSTRACT: The aim of this work is to bring closer the actors of building design and manufacturing process around a standard and commune building product definition. In the actual context a real problem of the building product definition exists: each actor has a specific point of view not necessary the same with the other actors. As a solution to this problem the paper proposes a conceptual model of the building as product using a systemic approach, and UML as formal modelling language. It constitutes the continuity of another works presented in the ITC@EDU workshop entitled “systemic approach for building design modelling”.

1 INTRODUCTION The paper is about a conceptual model of building product in collaborative design and manufacturing environment, based on a systemic approach and formalised using UML language. It evolves on three principal parts; the first part describes the building design and manufacturing context within actor’s interoperability. The second one focuses on the conceptual modelling as tool of interoperability, and the last one consists on the proposals of a formal conceptual model. 2 CONTEXT OF BUILDING DESIGN AND MANUFACTURING ACTIVITY In spite of the several actors concerned with the building design and manufacturing, the building sector remains one the rare fields excluding tools and methods dedicated to collaborative work. Nevertheless, it is strongly depending on the legal framework specif ic to each country. 2.1 Legal context In the current European context of building design and manufacturing, buildings are subject to a particular cutting of the life cycle regulated by the law. This legal framework constitutes a privileged instrument of management of the activities related to the building

eWork and eBusisness in architecture, engineering and construction

262

sector (Ameziane 2001). The MOP law (Maitrise d’Oeuvre Publique) which is specific to France, codifies the missions of each actor intervening in the building design and manufacturing process (D’A 2000) (similar laws exist in each country). In this cutting, the project of construction is born from an intention which expresses a need. This need is formalised by a program which expresses the requirements of the customer. Based on this program, a draft including conceptual solutions is then developed by actors of design. Starting from this stage, a Preparatory Project Summary is created and integrated into an administrative file for a building authorization. The development of the PPS will work out the Preparatory Project Detailed which includes the technical solutions evaluated by the partners of design (office of: structure studies, electric studies, etc.). This work leads to the realization of the Tender Documents to the Companies composed of the Plans of Execution of the Project and the Technical Specifications detailed. The reception of the project is the last stage in the life cycle cutting; it comes to mark the completion of the project. The building enters then in the phase of exploitation for which it was intended (Sahnouni 1999). 2.2 Towards a collaborative design The legal framework presented above constitutes a kind of method which influences the production of the building. In nowadays other methods of design initially conceived for the industrial sector come to influence the building sector. They are not always adapted to it (Design for manufacturing, systemic production, etc.) and only few of them can integrate it, in particularly: the concurrent engineering (Bignon et al. 1998). The tendency today is for this new method; which gives a margin of flexibility for the companies of building. These last are directed for their designs towards the co-operation and the exchange of information, around a co-operative process of building production. This co-operation is organized on the basis of information systems. It allows joining different knowhow on the same problem, in order to produce a solution. This solution would be only the compromise among the various points of view (of the architect, the engineers, the contractor, and of course of the customer). This method seems to be adapted to the building sector requirements. Concurrent engineering is the normal evolution to which the building sector should evolve. The continuation of this paper will take for objective to satisfy this need and will deal only with tools related to this method. 2.3 The conceptual modelling as a background of interoperability A great number of works about conceptual models in France were initiated (BOX, GSD, MOB, JUICE, TECTON, etc.), but also in the international area (ATLAS, COMBINES, MISSED, etc.), with a principal objective concerned on the description and the development of data building product models and building production process models (Ameziane 1998). These works were variously based on research laboratories from the academic world, with the assistance of institutional and industrial partners implied in the manufacture of hardware and the edition of software.

Product definition in collaborative building

263

The most important international action for answering the problem of interoperability with a conceptual model in nowadays is the project of the International Alliance for Interoperability “IAI”. It consists on the IFC model (Industrial Foundation Classes). The IFC model is different from all the precedent models in measurement that it proposes an extremely detailed structure of the building product (Billon 1999). This level of detail is justified by the fact that the IFC are a whole of resources, thought as a support to the building software publishers. The IFC propose the modelling of the building life cycle, structured according to four levels: – level 1: four general phases are identified: feasibility, design, construction, and exploitation of the building. – level 2: each preceding phase breaks up into a whole of secondary phases, organized according to a chronological order (the phase of design for example breaks up into: programming, diagrammatic design, detailed design, documents of execution, tender documents.). – level 3: each one of these secondary phases is declined in a series of chained processes, which correspond to the various actions of the designers during the project. They establish continuity in the cycle of design. – level 4: finally each process breaks up into a whole of activities. Each one of it is associated to a diagram, in which are described the tasks to carry out, also indicated in the model by “methods of design”. It is to note that these works have relatively close ambitions. It is question of facilitating the communication of information relating to the building product among the actors using a conceptual model. The principal idea in this tool is to model the building product as a whole of objects evolving in a process of production. It is important to know that this vision is very restrictive of the reality. 3 A SYSTEMIC APPROACH FOR BUILDING DESIGN MODELLING Going beyond the actual cutting in the building design and manufacturing process (by a conceptual model) means first of all the reconstitution of an informational continuity in the building life cycle. We propose to intervene on this cycle according to a systemic approach regarding the world of the building as being not a multitude of distinct elements (as in the actual models), but as a single “system” integrating a set of components in interaction (Le Moigne 1977). The “building system” is the set of human, material, and immaterial components intervening in the activities related to the life cycle. The system limits are the terminals characterizing the life cycle beginning and end. The system inputs are data characterizing these components and the outputs are the system levels of production (Oumeziane 2004). Our paper untitled “A systemic approach for building design modelling” presented for the ITC@EDU workshop introduces in four pages a conceptual model of the “building system” proposed instead of the actual traditional life cycle. Based on these results, the present paper proposes a building product definition in the building system.

eWork and eBusisness in architecture, engineering and construction

264

3.1 From the “building system” to the “building product” The installation of a systemic framework of building design and manufacturing includes the definition of the building system, but also the definition of the building product produced in this system. Is it a set of different objects? Is it a set of spaces? Is it a service offered in a defined space? These questions show well that there is a basic problem in the building production related to the product definition. The actual conceptual models introduced in this paper, consider in the major part of the cases, the building as an assembly of objects (problem of limitation of objects), and a whole of rules defining the relations between these objects. 3.2 Relativity of the product building definition In practice, it is very current to relate several and different definitions to only one building product. It is possible to distinguish two categories of views able to define the building product. A category of actorsproduct view and another one of stages-product view. In the first category, the product is related to an actor view. In general the point of view of the economist participant to a project constitutes a compromise among the actors. The building for the economist is seen as a set of objects and batches of objects. The other actors have their own point of view. The architect for example sees the building according to his personal convictions and according to his artistic tendencies. He considers the building as a whole of full and vacuums, a whole of spaces served and spaces given a service. An engineer of structure has a view considering the building as a mechanical model, and so one (AFITEP 2000). In the second category, the product is related to a stage of the life cycle. It is an infrastructure, a superstructure, an envelope, and so on until it becomes a finished construction assigned to a service. In the continuity of the approach undertaken (system approach), all the points of view of actors contributing to the production, must be taken into account and all the stages of the life cycle. The definition given to the building product is in this case “variable” evolving in a set of actors and stages. From this fact a first conclusion can be done: the definition of the building product is relative respectively, to the actor’s point of view and to the stages of the building life cycle. It cannot be restricted to only one actor point of view or only one stage of production. The product building becomes then definable on a set of views and different stages; it is variable. 3.3 The building product variable in the building system The building product is the variable component on the set of the stages of the “state of design” (the state of design is the state of the building system including all the stages of: feasibility, programme, APP, APD, etc.). In this state of the building system, the output consists on a wallet of documents (plans, etc.) representing a first form of the building product definition (Oumeziane 2004).

Product definition in collaborative building

265

Figure 1. The semantic of the building product definition. The design in this state of the system is organised according to a representation of three referential: methodological, conceptual and normative (Oumeziane 2004). Defining the building on this base means give a “semantic” definition taking in account the actor’s point of view represented in the referential (Fig. 1). We go then from an ineffective and traditional representation of modelling built around building objects and their processes of realization to an effective and more adapted representation built around referential. The structure of referential frames which was set up must permit to define the building product compared to a semantics built around several actors point of view (Martin 2001). It permits to identify the product by particular characteristics established in the course of production in the first state of the system (state of design). However, the semantic definition obtained should be completed by a syntactic one. It is important to remember that it is a question of a systemic approach where it exist two types of equality between the components, a syntactic equality, and a semantic one (Giambiasi 2001). In a semantic equality it is possible to define two different elements in their form but similar in their function as equivalents. As example a chair used to break a window, and a hammer, are thus equivalent in this case, they are used for the same function. Our first definition of the building product in the preceding figure must integrate fully this aspect of semantic equality. A syntactic equality considers equivalent only similar elements. The equality hammerchair becomes false from a syntactic point of view. In order to define a syntactic framework for the semantic definition proposed above, we will be interested in the formal systems. A formal system is a system with only syntactic equality and rigorous reasoning (Johnson 1970). (In the semantic definition of our product, the reasoning is not rigorous, because the actors reason by analogy, comparison, induction, etc. In the rigorous reasoning there is only one rule to reason: deductibility).

eWork and eBusisness in architecture, engineering and construction

266

Figure 2. Syntactic structure of the building product definition. Following this approach the building product can be compared to a number “n” pertaining to a mathematical set. For example an unspecified construction, can be assimilate to a global set of products (general product of consumption), to a typological set (product from the same family), to a die set (product of the same constructive die) and to a components set from a purely formal point of view.

Product definition in collaborative building

267

Compared to the mathematic construction of sets, a number “n” in a formal definition can be seen as pertaining to a general set R including all the real numbers, to sets K, J, and to set N including the natural numbers. Four sets of definition are obtained then, overlapping from the smallest to the largest, constituting a syntactic framework in which is defined the variable component “the building product” (Fig. 2). Accordingly, the building product cannot have any possible semantic in this purely formal construction. The idea to present the building as element of socialization, element founder of a culture, etc., is thus not taken into account in this definition. An undivided component of the building (beam, column, window, furniture, etc.) will be able to be defined on the fourth set, an element of structure on all the sets except the components set, a particular kind of building on the two first sets only, and a whole of buildings on the first set only. 3.4 A conceptual model of the building product By associating the syntactic framework to the semantic one, it becomes possible to characterize perfectly the production of the building system, a building product. According to the conceptual model obtained, the building system will be able to produce, with the same means and referential tools, a whole of buildings in the global level, specific buildings in the typological level, structures of building in the die level, and even components of building in the last level, with the same objectivity and the same architectural vision that will be define in our referential framework. Each level will indeed utilize a methodological, conceptual and normative referential as shown in Figure 3 next page. A house will be defined in this model as: a whole of products developed in different trades (electric components, air-conditioning, floor covering, etc.) taking an architectural semantic conceived according to a referential framework (methodological, conceptual and normative). It will be defined also on a set larger compared to a constructive die: wood, metal, etc but always with a specific semantic to this level defined by the referential framework. In the third level the house is defined as a building distinguished by its function, extremely different from another type of building. Finally it is defined in a set which contains all the precedents and allows making a distinction compared to the physique and social environment of the house. It is possible to define also in this diagram a simple component of a building, initially as a unified product, then as pertaining to a constructive die, then to a type of building, and finally as product influencing the external environment of the building product. The informal model obtain allows to produce a building or just a component of building according to a semantic built around referential framework and a syntax structured by sets of appurtenance. The next paragraph is about a formal representation of this model adapted to data processing implementation. 3.5 Formal model of building product and UML capacities UML (Unified Modeling Language) is a means of expressing object models by disregarding their implementation; that means that the model provided by UML is valid for any programming language. UML is a language relying on a meta-model, a model of

eWork and eBusisness in architecture, engineering and construction

268

higher levels which defines the elements of UML (usable concepts) and their semantics (their significance and modes of use) (Fowler 2002). As first results the Figure 4 is a synthesis of the paper presented in the ITC@EDU workshop and this paper. It consists on a model representing the building product classes and the building system composed of the actors’ classes, the tasks classes assigned to the actors and the tools classes used for that. It includes also the representation of the building system states, its output and the referential used in the state of design (Oumeziane 2004).

Figure 3. A building product definition.

Figure 4. A formal model of the building product.

Product definition in collaborative building

269

4 CONCLUSION Setting up a framework of interoperability in the building sector should passes initially by a conceptual level of modelling. The various current models which are used as a basis for the collaborative design deal with only a part of the reality of the building product. These models reduce the building product to an assembly of physical objects. The paper proposed through a product definition more general and more complete taking base on a systemic approach and formalized in a multi-referential language “UML”. This work constitutes the beginning of a model more complex of the “system building” including the roles of actors, the design methods, etc. We project to present in our ftiture publications the detailed of the referential framework proposed (conceptual, normative and methodological) in our building product definition. REFERENCES AFITEP, 2000. Le management de projet, principes et pratique. Paris: AFNOR. Ameziane, 1998. Structuration et représentation d’information dans un contexte coopératif de production du bâtiment. PHD thesis, Ecole d’Architecture de Luminy. Ameziane, 2001. Building Production Management systems in a cooperative work, IEPM ’2001, Quebec City, Canada. Bignon et al., 1998. Evolution de la mâitrise d’œuvre, pratique coopératives et informatique répartie. Conférence Mieux Produire ensemble. Plan construction et architecture. Nancy. Billon, 1999. Comprendre les concepts des IFC. Décrire son projet en vue des échanges. Paris: cahier du CSTB. d’A, 2000. La loi MOP mode d’emploi. D’architecture. Paris: SEA editions. Fowler, 2002. UML. Paris: Campus Press Poche. Giambiasi, 2001. Dynamique des systèmes. Course of Master in MCAO. Marseille: Polytech’Marseille. Johnson, 1970. Théorie, conception et gestion des systémes. Paris: Dunod. Le Moigne, 1977. Théorie du système général. Paris: PUF. Martin, 2001. Process design modelling through methodological integration. PHD thesis. Paris: Ecole Centrale Paris. Oumeziane, 2004. An adapted software environment for building design and manufacturing. IDMME2004. Bath City. Oumeziane, 2004. Systemic approach for building design. ITC@EDU conference. Istanbul.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Implementation of the ICT in the Slovenian AEC sector T.Pazlar, M.Dolenc & J.Duhovnik University of Ljubljana, Ljubljana, Slovenia ABSTRACT: The AEC (Architecture, Engineering, and Construction) sector is proverbially marked as traditional, not progressive oriented towards the new technology implementation. In order to determine the punctuality of the stated prejudice and evaluate the sector ICT (Information and Communication Technologies) implementation, a unified European state-of-the-art analysis has been made. One of the prodAEC, a two year pan European program, deliverables has been used for gathering the relative information. This paper presents the comprehensive ICT implementation analysis of the Slovenian AEC sector with structuring the results in different sub areas.

1 INTRODUCTION People involved in the construction informatics share a common objective irrespective to the terms used for their work description. Supporting of all participants in the construction industry in their individual tasks, and even more, in their synergistic collaboration should strive towards the optimal design, construction, operation, maintenance and removal in less time and with less cost. The knowledge contributed is presented in the forms of product and process models, tools and representations serving all participants (teams, individuals) in the construction process. All general estimations regarding to the debated issues emphasizes the huge difference between academia/research sphere and practice, quite matching the mentioned general public prejudice. Before making any accuracy estimation or prediction, the state-of-the-art analysis is required. Several investigations referring to the ICT implementation in the AEC sector were carried out (IT Barometer, SIENE Network and others), but most of them were time and geographically limited. Consequently, a conception to overcome the described restraints with a new international joint research has occurred. 2 PRODAEC PROGRAM 2.1 Program objectives The Fifth European Framework Program sets out priorities to the technical development and implementation of the user-friendly information technologies. These priorities have

Implementation of the ICT in the slovenian

271

been associated in the IST program (Information Society Technologies) on the basis of a set of common criteria reflecting the major concerns of increasing industrial competitiveness and the quality of life for European citizens in a global information society. ProdAEC, a two-year pan European IST program, main objective is to set up and sustain a thematic network for product and project data exchange, e-work, e-business in architecture, engineering and construction. Program main motivations and goals are: – to become the primary source of information for standards on data exchange, e-work and e-business in the AEC/FM (Architecture Engineering Table 1. ProdAEC founding members. Member

Country

e-mail

AIDICO*

Spain

http://www.adico.es/

UNINOVA

Portugal

http://www.uninova.pt/

VTT

Finland

http://www.vtt.fi/

CSTB

France

http://www.cstb.fr/

Hass+Partner

Germany

http://www.de-hass-partner.de/

Taylor Woodrow

UK

http://www.taywood.co.uk/

STABAU

Netherlands

http://www.stabau.nl/

TUD

Germany

http://www.tu-dresden.de/

UCBL

France

http://www.univ-lyonl.fr/

UL—FGG

Slovenia

http://www.ikpir.fgg.uni-lj.si/

Cervenka

Czech

http://www.cervenka.cz/

BIC

Italy

http://www.bicnet.it/

ANTARA

Spain

http://www.antara.net/

AEC3

UK

http://www.aec3.com/

* Project coordinator.

Construction/Facilities Management) sector for Europe; – to increase SME (Small and Medium Enterprises) competitiveness through the adoption and implementation of standards, thus positioning SMEs at the same level of opportunity as large companies; – to encourage progressive harmonization of overlapping standards; – to support and bring together national, local and industrial initiatives promoting the development and use of standards in the AEC/FM sector; – to provide an extensive process-based overview of project modeling standards; – to stimulate technology and know-how transfer from knowledge centers to the industry; – to improve both working methods and people’s qualifications by using standard practices.

eWork and eBusisness in architecture, engineering and construction

272

2.2 Program product and services Comprehensive prodAEC network potential users range includes industrial associations, software vendors, research community, standardization bodies, public administration and AEC industry in general. Project deliverables are gathered into four products and services: 1. Web AEC IT Project database National and European database of IT related project on the AEC/FM sector incorporating sensible search and filter engine query. Details and scope, scheduling, financing data, description, objectives, results, areas and partnership info are available for each project. 2. Standard-to-Process Matrix Service incorporates a reference framework for whole construction process with the identification of actors and their associated role. ProdAEC extended the process matrix to incorporate the concepts of modeling, data exchange and ebusiness standards. 3. Informative on AEC e-business An online service providing e-business information in terms of e-marketplaces, software tools and public e-services and presenting the general figures about debated topics. 4. Benchmarking Service The need for online benchmarking service, designed for the ICT exploitation and awareness level in the European AEC sector has been clearly marked in previous projects industrial requirements initiatives.

3 PRODAEC BENCHMARKING SERVICE 3.1 Benchmarking concepts Benchmarking in general presents a process of identifying, learning and adapting outstanding practices and processes from any organization anywhere in the world in order to help an organization improve its overall performance. The discussed service aims are more specific: – it concerns people active or linked to the European AEC sector (industry and government agencies, sector associations, research and consulting organization and software vendors); – compare the relative position in the ICT use & awareness to the companies of the same profile/ segment; – probe the views of different respondent groups; – relieve defining an appropriate investment in the knowledge acquisition & technology evolving; – identify lacks in the ICT awareness level and implementation at industrial level; – keep the track of the future requirements and sector evolution.

Implementation of the ICT in the slovenian

273

The Benchmarking service is available online, absolutely free of charge. All categories of enterprises in the AEC sector are covered with the unified questionnaire and everyone involved in the sector is welcome to participate in the enquiry. Its dynamic makes the service unique. After filling in the basic identity questionnaire, users receive the username and password via email. An immediate automatic feedback is generated in the personalized reports form after filling in the questionnaire. Ensuring the report coherency, only companies with the similar profile are used in the report generation. The dynamic system allows participants to revisit and check the results anytime and anywhere. Each participant has to fill in the questionnaire periodically ensuring the automatic database update. Therefore, the company evolution can also be monitored. The benefits of the benchmarking service are mutual. Answering the questionnaire is rewarded with the personalized reports where the competitor's data are offered without any special effort of collecting them. The industry participants can use the reports to define appropriate investment in the knowledge acquisition and technology evolution within the company. The government agencies, sector association, research and consulting organization can obtain even more benefits: – identify lacks in the ICT awareness level and implementation in industry; – updated knowledge about the actual awareness level and status of the ICT in AEC sector; – identify the training needs; – to collect data for designing future innovation public policies; – get valuable data influencing software product development strategies per country (and/or) per sector. The service requires no special maintenance since the operation is completely automated. Maintenance with additional costs would appear only when modifying or preparing new questionnaire. If the users find benchmarking service useful, they will check the results regularly and therefore provide the requisite answers for the database. Although the prodAEC is a twoyear program, the zero operation costs could keep the network and tools developed continue in the future. 3.2 The questionnaire The inquiry based methodology covering the ICT, drafting, modeling and e-commerce is used in benchmarking. Semantically, the questionnaire is divided into four parts: – A: Company information (company profile, size and turnover, participant individual data—involvement, etc). – B: Use of the computerization, modeling, e-commerce, EDMS (electronic data management system). – C: Classification, exchange standards, reference libraries. – D: Training, organizational and human issues. The questionnaire is available in English, Dutch, French, Portuguese, Czech, Slovenian, Spanish, Italian and German language. Enquiry generally takes 20 minutes to complete.

eWork and eBusisness in architecture, engineering and construction

274

3.3 The benchmarking service promotion In order to assure appropriate startup enquiry database, the intensive project/service demonstration has been required. University of Ljubljana, for example, put a lot of effort in the benchmarking service presentation. Various grips were used: – scientific paper about prodAEC project has been published in the Slovenian Civil Engineering Journal; – personal email invitations has been sent to all members of the Civil Engineering Chamber and to all employed in the academia and research institutions; – prodAEC presentation at the Slovenian Civil Engineering Cluster workshop. The intensive benchmarking promotion helped us to establish the most comprehensive, but not quite satisfying database as presented in Chapter 5. 4 AEC SECTOR GENERAL STATISTIC More than 26 million workers are involved in the European AEC sector: 28.1% of the industrial employment is dispersed in 2.4 million enterprises. Over 97% of them are SME (small or medium enterprises) with less than 20 employees and 93% with less than 10 workers involved. Short term (generally just single project) collaboration increases the AEC sector crumbling. Consequently, even the biggest European construction enterprises cannot take over the market leadership role since their share does not exceed 5%.

Figure 1. Person in paid employment in the European Union (construction sector only).

Implementation of the ICT in the slovenian

275

Figure 2. Person in paid employment in Slovenia (construction sector only). The Slovenian AEC sector does not defers much from the European. The enterprises percentage is a bit lower (25.8%), but the sector still remains the biggest industrial employer with more than 140.000 people involved. The sector is even more crumbled than the European: 95% of SME employs less than 10 people and 98.4% of them with less than 25 employees. The average enterprise has only 3.4 workers employed (including the owners). Further, Table 2 and Table 3 present some relevant statistical data referring to the Slovenian AEC sector. The person in paid employment increased in 1993–2000 for only 22%, but the value of construction put in place increased enormously (4.2 factor). The Table 2. Review of the Slovenian construction industry development. Year

Enterprises*

Employees

Value** (mio euros)

1993

1532

31722

452

2000

2608

40841

1680

* Number of enterprises and other organizations. ** Value of construction put in place.

eWork and eBusisness in architecture, engineering and construction

276

Table 3. Nominal indices of the value of construction put in place, March 2004. Time

III 2004

III 2004

III 2004

Period

II 2004

III 2003

III 2000

Value

111.6

109.9

109.4

National Motorway Construction Program that started in the beginning of the nineties had an important influence on incensement. The indices of the value of construction put in place shows the promising prognosis. 5 ENQUIRY RESULTS 5.1 General information The inquiry results are based on the responses (43) having been collected in the benchmarking service until April 2004. Although University of Ljubljana put a lot of efforts in the Benchmarking service promotion, the response was under all expectations. Since we do not know the exact number of people familiar with the inquiry, it is impossible to estimate the percentage of responses. Generally, the response in comparable surveys when informing the potential participants with e-mail message is very low—10–15% in IT Barometer (Samuelson, 2002). Evidently, it is hard to persuade the target e-mail recipients about the mutual benefits of such service. All observations and conclusions as the result of the prodAEC Benchmarking service presented in this paper are therefore based on a limited population. The equal participant role is presumed in the results analysis. No answer weighting is necessary. More participants foreseen from the big companies will compensate the large number of those employed in the small enterprises. 5.2 Part A: Company and user profile First part of the questionnaire contains the essential questions for creating the image about the participants and furthermore for the inquiry results filtering. As expected, most of the answers (54%) came from the design offices. Presumably they were the best informed about the Benchmarking service. The low ICT implementation in the AEC sector is usually referring to the construction—the participant percentage (10%) probably confirms this estimation. The share marked as “other” presents the answers from the research/academia institutions. No feedback (not a single answer) from the Public administration was considerable disappointment. After taking into the consideration the crumbliness of the AEC sector we can expect the high percentage (almost 50%) of enquiry participants employed in the small enterprises (<=10 employed). The 25% share of the medium-big companies (51–250 people employed) justified our assumption about the unnecessary answer weighting. Since there are only two construction companies in Slovenia with more than 500 people employed, their participation share (3%) is also anticipated.

Implementation of the ICT in the slovenian

277

The answers about the annual turnover can be linked to the answers about the enterprise size. More than 50% of them have the turnover less than 0.5 mio euros. If we set the limit to the 5 mio euros, more than 90% of survey participants are captured in the analysis. Figure 4 presents the enquiry participants role in the enterprise. Since the participants from the smaller enterprises are commonly involved in more than one area of interest, they have picked up more than one answer and automatically weighted the area importance. Generally, the collected response presents mostly the architects and engineers involved in the design, construction and project development and partly operation. The first paragraph assumption about the inquiry participant role in the AEC sector is confirmed with the answers about undertaking work location. More than 80% of participants usually undertake their work in the main or area office instead of on-site. 5.3 Part B: Technological infrastructure The first step in the computerization, modeling, e-commerce, EDMS usage evaluation is the technological infrastructure implementation. Internet and e-mail are the most accepted modern ICT in the AEC sector. Every participant has access to the both technologies, but only two thirds use them. Similar results are valid for the CAD system usage too. It is difficult to understand why 32% of people who owns the digital photography equipment do not use it. We are certain that this technology usage will increase rapidly in next year or two. Telephone and video conferences with the result of 15% and 12% are not so disseminate. The usage percentage is much lower than the ownership in both cases and indicates that users don’t find those two types of technologies very useful. Presumably, the main cause can be found in the technical difficulties usually present in the conference usage (like low band width, etc).

Figure 3. Company profile.

eWork and eBusisness in architecture, engineering and construction

278

Figure 4. Areas of involvement. Further we investigated the area and level of computerization Three answers were offered referring to the usage: low <20%, partly 20% <−60% and high >60. The bookkeeping and invoicing presents the areas with the highest estimated use of computerization. More than 45% indicated their usage as high. The bills of quantities, costs, budgeting and project management closely follows with 30%. The computerization level in building elements, civil engineering elements, building services (HVAC), and construction reaches up to 25%. Consequently, the enquiry participants can be divided into two groups: users with the high level (one quarter) and users with the low level of usage (three quarters), regarding to the answers about their computerization usage. Other areas—building elements, environmental impact, estimating, facilities management, health & safety, project development are very low ranked (below 10% high usage). The partly usage of computerization (20%–60%) in all areas except planning, scheduling, product catalogues & details and project management is also below 10%. A simple conclusion can be obtained: If the users have technology, they use it. The most common software tools used in all areas are the office software. Special software tools are used mostly in the bookkeeping, invoicing, planning & scheduling, project management, costs, budgeting and bills of quantities. 2D and 3D CAD application are common only in the building elements & services, civil engineering elements and in construction. Low data exchange ratio can be concluded. 2D CAD systems are still a preferred choice for almost two thirds of actual users. One of enquiry intentions is also an estimation of the ICT developments in the near future. The most concerning fact obtained from the Figure 5 is the lack of specific plans referring to the further e-business application usage. The market pressure should be established in order to ensure the new technologies implementation. The current state-ofthe-art showed no such pressure (35%). Only the customers (30%) are forcing participants to adopt e-business solutions. Surprisingly, almost no pressure comes from the public authorities. The opposite proposal, to move from traditional to the e-business methods, can put in danger 10% of established partnerships. One third of the participants found out less costs, time and errors (most important benefit), process simplicity and fewer errors as the main benefits of the e-technologies regarding to the account/finance area.

Implementation of the ICT in the slovenian

279

Figure 5. Technological infrastructure.

Figure 6. Plans for the ICT investments.

Figure 7. Level of awareness. E-technologies in procurement, commerce and enterprise resource planning do not currently present such benefits. This estimation can be put under question mark since the applications use percentage is low and therefore cannot reflect the real benefits. The participants also do not estimate the e-technologies as an important factor in assuring the new customers and in loyalty increase. The level of awareness in the modern technologies in the AEC sector is insufficient. None of the answers

eWork and eBusisness in architecture, engineering and construction

280

Figure 8. Awareness and usage of drafting and data modeling standards.

Figure 9. Awareness and usage of digital data capture, logistics and automation technologies.

Figure 10. Training methods. (EDI and private networks, XML, electronic commerce, mobile devices and remove connections to software tools, electronic marketplaces, specific standards for AEC, electronic services of private companies for AEC, electronic signature and digital certificates) reaches more than 50%. Extremely low is the awareness percentage in the AEC standards. The use of the described technologies is also poor (below 10%). The only exceptions are digital certificates and electronic signature with the 20% usage. Those two technologies will assure the necessary security for other applications (electronic commerce, etc.). Solving the security

Implementation of the ICT in the slovenian

281

Figure 11. ICT effect on enterprise operations and job roles. problem will increase not just the level of awareness, but also the level of usage in discussing areas. The cost of the software solutions presents the mai obstacle (22%) for adopting ebusiness in the enterprises. The second group of barriers includes the dependence of proprietary solutions, expensive external know how, lack of available know how inside the company and poor adequacy of solutions to the industry needs are all ranked with 10% each. The lack of trust in the available technology and the workers/partners resistance (max. 5% each) does not present important obstacle. The overwhelming share of participants (more than 80%) does not have any plans regarding to the EDMS (Electronic Data Management Systems). Where used, systems are usually accessed via LAN or ADSL. 5.4 Part C: Standards Most of the classification systems stated in the questionnaire are completely unknown to the Slovenian AEC sector. No one uses them and no one plans to use them. The participants are acquainted only with the existence of Building 90, Landscape Filling Index, CAWS, European Waste Catalogue andNational Green Specification. The awareness in each case does not exceed 5%. The reference libraries implementation analysis presents similar results. Only few of the stated libraries (AEC/ Bricsnet, Architects Standard Catalogue, BertelsmannSpringer, COIB, Emap, Fraunhofer Informationszentrum Raum und Bau) are known to the enquiry participants, but no one uses them. The awareness and usage of the drafting and data modeling standards (Figure 8) reflects the state-of-the-art on the CAD systems dissemination. AutoDesk software is most widely used and the figures presenting the .dwg and .dxf format were expected. The GDL and IGES standards are also known. Surprisingly low awareness about IFC and Cimsteel standards is probably connected with predominant 2D modeling. A general lack of awareness can be perceived in the electronic trading technologies including the digital data capture, logistics and automation technologies. Only the electronic data interchange (EDI), hand held digital data capture and XML are used. Barcodes, transducers and already stated technologies present theareaof interest.

eWork and eBusisness in architecture, engineering and construction

282

5.5 Part D: Social, educational and organizational aspects Regardless to various possibilities of educational methods offered by modern ICT (video, internet), the traditional compulsory and formal courses are still the most common way of education for all employees. The knowledge transfer inside companies can also be comprehended from the answer, since the enterprises stress the compulsory education for the managers, professionals and technicians. According to the participant’s estimation, the advanced ICT will have the significant effect on the job and skills, contractual relationship and on the way companies works. Surprisingly big percentage of participants is convinced that ICT cannot reduce the number of employees. The percentage in nearby future will probably lowered with data exchange standards implementation. Although the estimations, gathered in Figure 11, do not lean on the statistical data, they still present the valuable projection of the AEC sector in future. 6 COMPARISON WITH THE EUROPEAN AEC SECTOR Unfortunately the other ProdAEC partners have not started with the Benchmarking service presentation in their countries until the mid May 2004. No data from the debated service was available and therefore no comparison could be made. 7 INVITATION The statistic provided by prodAEC Benchmarking service can be marked as credible only if the adequate number of people involved in the AEC sector will fill in the questionnaire. If you find yourself as potential Benchmarking service user, please visit the ProdAEC web page (http://www.prodaec.com/) and participate in the enquiry. 8 CONCLUSION The prodAEC Benchmarking service presents a pioneer’s attempt to set a unified method in measuring the ICT implementation in the whole European AEC sector. Although the enquiry concept and realization can be marked as exemplary, more intensive promotion should be made. It’s concept to automatically collect answers just on the mutual benefits basis is presumably too contemporary for the prosperous enquiry accomplishment. Minor changes should be applied to the questionnaire according to the participant comments about too long and too complex questions. The enquiry revealed a lack of awareness on advanced ICT in the Slovenian AEC sector. The current AEC sector state-of-the-art analysis showed needs on immediate improvements, but we cannot mark the described situation as an obstacle to the creativity in the concerning sector. The answers indicate the market pressure as an efficient inducement for implementing the new technologies in practice. One of the most concerning analysis results is the lack

Implementation of the ICT in the slovenian

283

of specific plans for the enterprise future ICT investments. New technologies should focus on improving productivity (less time, costs fewer errors and process simplicity) and be implemented through the user friendly information and training. Furthermore, the academic and research institutions must stay in contact with current achievements in ICT and also with the practice requirements in order to ensure the sector development. REFERNCES Fenves, S.J. 1996. Information technologies in construction: A personal Journey. In Ziga Turk (ed.), Construction on the information highway. CIB proceedings publication 198, Bled, 10–12 June 1996. Ljubljana: University of Ljubljana. Faculty of Civil and Geodetic Engineering. Rivald, H. 2000. A survey on the impact of information technology in Canadian architecture, engineering and construction industry. Electronic Journal of Information Technologies in Construction 5: 37–65. Samuelson, O. 2002. IT barometer 2000—The use of IT in the Nordic construction industry. Electronic Journal of Information Technologies in Construction 7: 1–26. URL: http://www.prodaec.com/ [1.6.2004].

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Adding sense to building modelling for code certification and advanced simulation I.A.Santos & F.Farinha Algarve University, Portugal F.Hernandez-Rodriguez & G.Bravo-Aranda Seville University, Spain ABSTRACT: IFC-based models seam very promising for automated code checking because they are expected to include the heuristics needed by several applications during the building lifecycle, thus including the capability to support the definition and checking of a large set of requirements together with those contained in building codes. However, the theoretical and practical aspects of the IFC-based modelling, as well as the kind of the desired code checking assistance, still result in the necessity of dramatic support from cognition-based techniques in order to evaluate the presence of sense in each building description, specially when the certification of a building plan is the goal. This paper discusses these issues following the formerly developed concept of a Normative Product Model. Three main topics are discussed: (1) trends and limitations of IFC in respect to building simulation; (2) a contribution for the essential notion of building sense, including the identification of its admissible sources; and (3) the relevance of building sense to achieve for the self-completeness of a particular IFC-based building description starting from an initial low level user input.

1 INTRODUCTION As computers increasingly stimulate automation and greater efforts are being dedicated to develop building models with enhanced representation capabilities, the question of an automated code certification is certainly a challenge. To achieve this goal, the building model must include much more data than it traditionally does, and it shall no longer be dependent on human interpretation. In fact, the building model must include knowledge and become a true building simulation with complete, accurate and integrated references to all aspects that may be relevant for the code checking. Since this is certainly beyond the usual approach of sensitive visual modelling, it may be referred as advanced simulation. Besides, for the technology that can make this possible, each clause from a code that can be automatically checked becomes essentially a design requirement, for which the building model provides the necessary information resources and operating instructions. So, the same building simulation technology can be used for the checking of other sets of

Adding sense to building modelling for code certification

285

design requirements, whether they originate from a particular building program or relate to some specific analysis.s This paper follows the concept of the Normative Product Model (Santos et al. 2002, Santos 2003) described in Figure 1, accepting that the IFC standard (IAI 2003) is a basic component of such an advanced building simulation, but it focus on the necessity of developing formal definitions of building sense as an ultimate component, not only to allow for the automated checking of design requirements but also to enhance the completeness and accuracy of a building model, and still to support the design process. Besides, this paper states the exclusive role of building codes as the main source for building sense, among others. The contribution of IFC for advanced simulation is first discussed, followed by the characterization of distinct levels and contexts related to the automated checking of building design requirements. Then the question of building sense is introduced, its relevance for code certification and model completeness is described and its fundaments are discussed. Finally, some conclusions are emphasized. 2 CONCEPTUAL LIMITS OF IFC In the attempts to enhance building modelling, the main goal is not exactly about simulation but “simply” to

Figure 1. Fundaments of the Normative Product Model concept.

eWork and eBusisness in architecture, engineering and construction

286

allow that everyone on the world can share a single and common view of a building, at least to a certain extent and quality that may be considered convincing by the industry judgment. This view is expected to: (1) become a standard; (2) cover the entire building lifecycle; (3) be independent from particular requirements; and (4) bring no limitations to the design solutions, soon at the early phases of the design process. However, to enhance building modelling starting from today’s practice, sooner or later it means facing the real world, where things that are put together usually interrelate and even interact. So, an enhanced building model technology must also support a great number of interrelations and dependencies between building elements, which may outcome as a difficult trend, not only for software implementation, because of database management problems, but also for the users that become responsible for the introduction and assessment of building model data, much more than presently (Bazjanac 2002). The evolution of the IAI design for the IFC standard seams to be more and more successful about the referred expectations, but it denotes some conceptual limits in relation to building simulation, which are more concerned to the quality of the modelling than with extension capabilities (probably as a result of lessons taken from the difficulties of previous attempts on standardization or implementation issues). The most important of IFC conceptual limits under this particular perspective is its conception as a building descriptive language, but also the flexibility of interrelation declarations and the possibility of partial implementations in software applications become relevant. 2.1 Conceived as a language The IFC standard is strictly conceived as a language to describe a building during its lifecycle: a building metamodel as referred by Santos (2003), meaning that it defines the abstractions considered necessary to develop specific building models. It includes a lexicon of generic designations, which starts from the most abstract level like “object” or “relation”, goes through medium abstract level like “building element” or “space”, and ends with the less abstract ones like “window”, “opening area” or “wall”. It also includes a grammar that identifies the allowed interrelations between the concepts of those designations. For example, it determines that a “window” has “opening area” as an attribute and it can be associated to a “wall” meaning that the wall “has openings” (by the “fills/voids” interrelation definition). However, IFC does not include any definitions of sense outside the very own metamodel context. It does not control, for example, if: the “opening area” of a “window” is related, by a certain formula, to the “space area” of an associated “interior space” (assuming that “space area” and “interior space” are, respectively, an attribute and a type of “space”). So, it’s possible to use IFC modelling resources to make an internally consistent representation of a nonsense building, almost the same way as one can use the English language with complete syntax correction, while not making sense, as in: “a dog without legs runs backwards”. Of course, since IFC is particularly dedicated to the building industry, the possibilities of incorporating some sense soon at the grammar level are bigger than with a common use language, mainly by means of the semantics embodied in attribute and specific

Adding sense to building modelling for code certification

287

interrelation definitions. But, especially in respect to an enhanced building simulation perspective, modelling just at a language level appears as an initial restriction to knowledge representation, for which something must be done. 2.2 Interrelation capabilities IFC defines interrelations between building elements (others than attributes) as model objects that intermediate between other objects, and this is one of its most important features, because not only it solves the implementation problem of “many-to-many” relations, as it becomes the basis for the structuring and pre-definition of the semantics of interrelations in a meaningful way for building modelling. However, the use of interrelation capabilities within IFC is fully optional, so one may use the standard simply for a listing of individual building elements (whether physical or conceptual), without making explicit acknowledgement of the multiple relations between those elements. For example, it’s possible to have walls surrounding a space, without declaring them as providing the “boundary” for the space (nor the space as “bounded” by the walls). Also a window can be placed into a wall without explicitly declaring it as “voiding” the wall. Certainly these issues can be largely solved by a good IFC implementation, where intelligent software tools can greatly improve its usage. But, even then, it may be difficult to keep a model data accurately updated concerning the interrelations, when successive changes are made. Ultimately, the result can be the tendency to a graphical representation only of building elements with a quite low simulation power. 2.3 Partial implementations The IFC certification process, as determined by IAI, allows for partial implementations under the notion of model views (which are similar to conformance classes within STEP). It is expected that these model views do not reduce the interoperability, since they originate from applications within a same specific domain that share a common set of information requirements, far from the extensiveness of the entire model. However, these model views can also be used to hidden the limitations of present software applications and even generalize a low level usage of the model, which clearly turns to be negative regarding software’s interoperability and enhanced simulation. Once again, the seriousness of the problem depends on the quality of an implementation, at least by keeping untouched the part of a building model data that is not compatible with a specific application. But this will not avoid that either new data produced by a certain user ignores potentially important interrelations with “hidden” data, or that the results from some relation-based analysis can be inconsistent.

eWork and eBusisness in architecture, engineering and construction

288

3 BUILDING MODELLING AND AUTOMATED REQUIREMENTS CHECKING Much of the requirements of building design come from applicable building and technical codes. They represent the standardization of sets of requirements that are defined prior to the existence of a specific building. Actually, the possibility of defining codes relies on the fact that buildings tend to certain constancy on their spatial aspects, or the construction technologies or the included technical systems. Based on the constancy of buildings, some classification notions arise and the codes that are applicable to certain categories become generic requirements for the respective set of buildings, while particular requirements result from the building program, local conditions and some other sources. With the support of several modelling techniques, both sets of requirements can be checked prior to construction, at least if they fit into the representation capabilities of the building models. The regularity of checking procedures suggests that they can progressively turn from human-driven to automatic. The notion of automation here means the possibility of a process that demands some control actions to become executed by a computer, by means of previously formalized information and on-line collected data. For a requirements checking automation system, this means putting codes and other sources of building requirements into some sort of a computer operable representation, probably after a conversion from original paper-based documents or eventually as a former specification. Considering the kind and extent of such computer operable representation, three distinct levels of automation can be identified in the case of codes: code referencing, code checking assistance and code checking certification. They are discussed next, together with the question of particular requirements. 3.1 Code referencing Code referencing occurs when the selection of a single or complex building element from a building model, made by an user, automatically leads to the referencing, with possible presentation in text or graphics, of all related clauses from a set of treated codes, so that the user can easily get just the information he/she needs at that particular time. It is a human-driven approach, because only the user knows the meaning of the information contained in the building model as well as the meaning of code documents. To achieve for a code reference system, instead of any enhanced building simulation, it is basically needed a simple list of cross-references between the lexical content of the building code and the lexical content of the building model, which is perfectly achievable even for geometry-based modelling through commonly used tags. However, this kind of lexical definitions still presents a few significant problems, related to multiple classification, treedepth evaluation, etc., which are similar to those of classification systems used by the construction industry for materials and services acquisition (like CI/Sfb or Master Format).

Adding sense to building modelling for code certification

289

Once these cross-references are defined, an interactive system, possibly hypertextbased, can be developed and distributed as a program directly integrated with design tools, or as an Internet-based service. 3.2 Code checking assistance Code checking assistance occurs when the selection of a building element from a building model automatically leads to the checking of the relevant properties of its own, or other associated elements, according to the requirements of a set of applicable clauses taken from the treated codes, with the objective of detecting unconformity, and possibly to present alternatives. To achieve for a code checking assistance it’s necessary to go much further on the computer operable representation of the code than for code referencing. The building model needs to be meaningful, so that the checking system has enough knowledge about the building model, the building code and the logic correspondence between both, and takes consistent action. However, since the building model is essentially descriptive, but the code content is intended to be normative/declarative, while also descriptive (any code embodies a certain view of a building), the referred correspondence is expected to cover only the information requirements that concert to the description of a building, i.e., it relies upon a possible common building language, leaving the normative content to be represented by some distinct rule-based modelling. The Normative Product Model concept states that, for each clause of a treated code, the information requirements are considered at a base layer as a data structure that includes both lexical definitions and interrelations, while the normative content is represented by upper layer logical rules. Then, the data structure becomes the source for the correspondence with the metamodel that supports the building model, either by a mapping or by integration. Typical problems of this kind of code checking systems are: (1) ad-hoc solutions for the building model, when a true standardized modelling does not exist or does not provide the appropriate semantics; (2) poor correspondence between the building model and the content of the code, usually as a result of poor semantic capacity of the building model (most frequent with geometry-based modelling); (3) non homogeneous treatment of the code content, when some of its information requirements cannot be satisfied by the building model. Yet, this is the level of automation of the majority of the developed systems till now. For example, the SEED project (SEED 1997), which is one of the most serious attempts based on geometry-based building modelling, suffers from the referred mapping limitations, while the undergoing CORENET project (Liebich et al. 2002) looks much more ambitious with the exploration of the new possibilities of IFC on building modelling. Also some software applications for specific technical domains include a few capabilities of code checking assistance when the code information requirements are close to their own database specifications, but it is rather limited and not suited as a general approach.

eWork and eBusisness in architecture, engineering and construction

290

3.3 Code checking certification Code certification is a kind of code checking that is performed at crucial moments of a building lifecycle, possibly within a formal process of certification carried by some authority or control agent. When it occurs during the design process, it is particularly relevant as part of a strategy to prevent risk on building construction. Code certification is the maximum extension of code checking and it presents a severe demand in relation to the accuracy and completeness of a building model, because the entire content of the model is completely checked against all the applicable clauses of a certain code. Even when it is assured basically by human intervention, it is expected that the building model becomes a clear representation of the intended building, meaning one that shows all the relevant aspects of the building after a proper interpretation. Depending on the internal structure of a code, still it is possible to consider only a set of clauses, but only if the set is clearly identified and generally recognized as a detachable part. For a building model to be automatically checked for certification, it is expected to be totally meaningful and definitive in relation to the code. Final decisions about all relevant design solutions must have been made, must be clearly described in the model and must be kept unchanged for the future (if the certification is not to be repeated). In order to reach this level it’s critical to assure that the building model satisfies every information requirement of a treated code. As this can easily conflict with standardization trends, the building metamodel that supports the modelling must include flexible mechanisms for the representation of information requirements that cannot be directly supported by preset definitions. For example: specific space type identifications or specific property sets concerning a single element, required by a certain code (as it is just the case of object type and external property definitions within IFC). The referred Normative Product Model concept states the convenience, for code checking certification, that is to join several distinct codes that may work together within a specific time and territory, for a specific building category, beginning by those that may contribute with more general and structuring knowledge. Both layers of a Normative Product Model (metamodel integration and rule-based declarations) must be documented by some sort of an official specification controlled by the same authorities that are responsible for building codes, in order to have unique definitions within the same modelling support technology. Since an excellent correspondence is required, a special attention must be given to the relations between the data structure determined by the code and the global data structure of the building metamodel that is to be used. Model-based integration is better than simple linear mapping because of the complexity of the interdependencies among individual information elements. Code checking certification is, by now, still a dream, but it points out a main goal for future developments, though it demands global solutions and it will have impact on the own way that building codes and other requirements will be specified, as well as in the administrative processes of building design approval by official authorities.

Adding sense to building modelling for code certification

291

Building modelling for code checking certification greatly concerns building simulation. 3.4 Particular requirements checking By definition, particular building requirements cannot be generally defined, so it’s difficult to assure a good modelling support for them. However, the probability of an enhanced building simulation technology to provide better support is certainly bigger than with a merely graphical modelling. Among the many sources of particular building requirements, there are: (1) the building design program; (2) the building design constraints; (3) technical analysis not directly related to building codes; (4) the building management; and (5) the building maintenance. Also when some change on building configuration occurs, particular requirements can be identified for an appropriate evaluation of the impact of thatchange. 4 ADDING SENSE FOR MODEL REALISM Nowadays, when an authority receives a building plan and begins the process of checking its requirements for certification, the very first notion that is really checked is whether it looks like a building or not. In spite that, most probably, any code explicitly says that the specifications of a building plan shall in fact become a building, or at least includes an operable definition of what a building is supposed to be, the truth is that thinking of code certification in the case of a non-sense building, just sounds malicious. Now the authority probably looks first for some signals that may show the evidence of a building at a glance, and after he/she uses further analysis to confirm or deny the evidence. There are several conceivable circumstances where a building specification plan soon cannot be accepted as corresponding to a building, as when: – It is clearly incomplete; – It is not a single building (as expected); – It doesn’t refer to a foundation and site; – It is out of scale to human proportions; – There is no entrance; – Floors have too much angle; – There are undefined holes in outer walls; – There is no roof; – There are no fixed elements; – Axes are changed; – Everything looks mixed up; – There are non-identifiable elements; – Etc. Furthermore, it is possible to think of certain severe unconformities with defined requirements as resulting in a non-sense building too. For example: (1) the absence of the

eWork and eBusisness in architecture, engineering and construction

292

water distribution system; (2) the existence of individual spaces without entrance; or (3) the existence of too many apartments that do not conform to space requirements. For a human interpretation based checking, this kind of considerations may sound exotic, but for a computer-based automated checking it is a matter of major importance if the building model is expected to be realistic, even because the entire checking procedure becomes much less solemn and errors are easier to arise. So, there is an absolute need of some formal definition of how a building must be, not only by a positive approach, saying what a building is expected to be, but also by negative statements that can prevent unexpected occurrences. The previous considerations lead to the notion of the global sense of a building, from which results a verdict about a building model can in fact refer to a realistic building, or not. This global sense notion can take into consideration some building classification, resulting in selective references, like: “it’s a building of type X, except for this and that”; or “it’s a nonsense building in regard to type X”. The question of sense is always associated to code checking because, by definition, each clause of a code determines how something must be, or what makes sense about the building in relation to the code it belongs. However, global sense is somehow different because it first concerns the realism of a building simulation, which is an important quality of a building model, especially when an automatic code checking certification takes place. 5 ADDING SENSE FOR MODEL COMPLETENESS An automated code checking certification must be based on a reliable and complete building model, or otherwise its results can easily be false. This means that every building element shall be properly described and classified, and all its relevant relations with other elements shall be explicitly declared. Firstly, this depends on the capacity of IFC, as a building metamodel, to satisfy all the information requirements of the treated codes without exception, at least by the proper use of its extension mechanisms. Let’s consider an example from a Portuguese building code: in a house, the kitchen can never have a direct communication with a bedroom. In order to check this clause, the checking system can perhaps start by the detection of a kitchen, then looks for all the walls that surround it and for each one of them tries to find an opening (possibly a door or a window). If successful, then identifies the space to which the wall connects and sees if it is a bedroom type. But the result can be false if the space identifiers do not exist or are not compatible with the code requirements (not allowing the distinction between kitchen and bedroom types), or if the relation between a space and the surrounding walls is not explicit. So the demand of completeness really means to explore the simulation power of IFC modelling to the maximum, avoiding the negative tendencies that result from optional interrelations between identified elements of a building, as well as partial implementations in software tools. Besides, as a consequence of an intensive and extensive exploration of IFC resources, the operating environment must be capable of processing a dense network of data, specially for queries, both at high level (conceptual

Adding sense to building modelling for code certification

293

data) and low level (for example, when doors and windows are only geometrically related to walls). In fact, some problems can arise in relation to this increased amount of data and its quality: – The possibility of mistaken interrelations to be declared; – The possibility of users to forget relevant interrelations; – The corresponding machine processing cost; – The lack of specialized assistance; – Etc. For the first two of these problems it’s possible to develop software tools to go deeper into the analysis of a building model and help to prevent such errors by detecting important signals of possible occurrence. The kind of building cognition needed by these tools is also related to the notion of global sense, but here the emphasis goes for a probabilistic approach (not mandatory). So, besides the capacity of IFC, the reliability and completeness of a building model can be greatly improved by using sets of generic mles based on building sense, which can be customized by users as model types. Following examples illustrate this kind of rules: – Always an interior space type is expected to have an entrance; – Always a bedroom space type is expected to have a window opening to the external space; – Every space that is totally surrounded by walls is probably an interior space; – Every interior space area where a dishwasher exists is probably a kitchen; – Every interior space to which more than two doors are related is probably a circulating space type; – If a combustion equipment exists in an interior space, it needs the corresponding connection to an air exhaustion system; – Etc. The implementation of this kind of building cognition must consider the existence of multiple start points and directions to explore in the network of data of the building model, where the goal is to find the proper hierarchical structure and sequence of operations, in order to obtain the most quicker and effective results. Once formalized in accordance to the IFC capabilities, software tools that use this kind of building cognition can be integrated with user interfaces to IFC models, and become an important contribution to facilitate its use. 6 SOURCES OF BUILDING SENSE The main reason why a standard building metamodel like IFC cannot include rules of building sense, as those that have been described above, is that otherwise it would become generally restrictive to the design process in an unacceptable way for a building language level. The kind of knowledge associated to building sense is best intended as a filter for building model data, which is to be used in special moments of the design process (and eventually later on during the entire lifecycle) and which will be inevitably dependent upon particular building concepts.

eWork and eBusisness in architecture, engineering and construction

294

Besides, where is the legitimacy to determine what makes and what does not make sense in regard to a building? Building codes are the prior admissible sources to determine building sense, though they are just intended for that, not only by their content but also by the quality of being a recognized and general imposition over the building design. Besides, by the same reason that one shall not expect to find inconsistencies between the distinct codes that apply to the same building, the seek for building sense gains much more effectiveness if a larger and properly structured set of applicable codes is considered, because of the improved global consistency. Usually, architectural building codes provide more general definitions based upon space functionality, while more specific codes shall depend on these general definitions for their detailed views. That’s why the Normative Product Model concept also states that more general codes shall be considered first as a fundament for the formal definition of sense in a building. And it points to distinctive manifestations of the concept for each set of building codes sharing the same conditions of applicability (time period, territory, building categories, etc.). Nevertheless, even the most general and structuring building codes can become insufficient in regard to the kind of global sense that has been described. So, a second source must be considered, which is precisely the one known as “common sense”, and this shall be used only to complement building codes concerning the realism, reliability and completeness of a building model. Building codes and common sense can be considered the only admissible sources for the definition of building sense, at least within a normative perspective towards an enhanced building simulation. However, all other sources containing building requirements can also be considered for special objectives. Beyond the previously mentioned sources of particular building requirements, the so-called “codes of good practice” deserve reference, though they often represent the anticipation of important requirements that can only be properly checked much later during the design process. If a building sense relies on building codes and other particular sources, then there are multiple building sense definitions, some of them corresponding to a particular set of codes that embodies a specific Normative Product Model, while others simply become tools to support the design process. 7 CONCLUSIONS It has been shown that building sense is greatly important to enhance a building model towards an enhanced building simulation, through realism, reliability and completeness. This last achievement becomes especially relevant to stimulate the simulation capacity of IFC-based modelling. However, because building sense is not suited to become standardized, the Normative Product Model concept points to a kind of building modelling that includes two layers that can be referred as: building language and building sense. The first layer consists of an integrated metamodel that results from the integration of the structural information requirements of a building code into a standard metamodel like IFC, and its main content consists of object definitions. The second layer becomes a structured set of rules that

Adding sense to building modelling for code certification

295

represent the normative content of building codes, for which it uses the building language defined by the first layer, together with a standard formal language like EXPRESS. It has been suggested that this approach is also useful for any other situation of automate building requirements checking, once an integrated building metamodel can satisfy the particular informatSion requirements of the respective source. The incorporation of building sense and other requirements checking systems into design tools, using IFC as a standard base component, can greatly improve the design process, allowing for better simulation models at a lower cost and in shorter time. REFERENCES Bazjanac, V 2002, Early Lessons From Deployment of IFC Compatible Software, in Z Turk and RJ Scherer (eds.), E-Work and E-Business in Architecture, Engineering and Construction, Proc. of 4th European Conference on Product and Process Modelling, Portoroz, Balkema, Rotterdam, pp.9–16 IAI: 2003, [http://www.iai-international.org/iai_international]. Liebich, T., Wix, J., Forester, J. and Qi, Z: 2002, Speeding-up the building plan approval—the Singapore e-plan checking project offers automatic plan checking based on IFC, in Z Turk and RJ Scherer (eds.), E-Work and E-Business in Architecture, Engineering and Construction, Proc. of 4th European Conference on Product and Process Modelling, Portoroz, Balkema, Rotterdam, pp.467–471. Santos, IA., Hernandez-Rodriguez, F. and Bravo-Aranda, G: 2002, A Normative Product Model for Integrated Conformance Checking of Design Standards in the Building Industry, in Z Turk and RJ Scherer (eds.), E-Work and E-Business in Architecture, Engineering and Construction, Proc. of 4th European Conference on Product and Process Modelling, Portoroz, Balkema, Rotterdam, pp.473–480. Santos, IA: 2003, Modelizacion de Edificios de Viviendas para la Verificacion Automatica de Requisitos Formales Asociados a las Normas Generales de Construccion—Un Desarrollo Basado en los Estandares IFC y UML, PhD thesis, Dpto. de Ingenieria del Diseno, ESI, The University of Seville. SEED: 1997, SEED—A Software Environment to Support Early Phases in Building Design, The Carnegie Mellon University, USA, and The University of Adelaide, Australia, [http://seed.edrc.cmu.edu/IJDC/toc.html].

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Towards engineering on the grid Ž.Turk, M.Dolenc, J.Nabrzyski, P.Katranuschkov, E.Balaton, R.Balder & M.Hannus All: The inteliGrid Consortium, c/o University of Ljubljana, Slovenia ABSTRACT: Grids are generally known as infrastructure for high performance computing. However, the original idea behind grid computing was to support collaborative problem solving in virtual organizations (VO). A challenge for collaboration infrastructures is to support dynamic VOs that collaborate on the design, production and maintenance of products that are described in complex structured product model databases. Such VOs are typical for industries with long supply chains like automotive, shipbuilding and aerospace. Perhaps the most complex dynamically changing VOs and are in architecture, engineering and construction (AEC). Semantic interoperability of software and information systems belonging to members of the VO is essential for efficient collaboration within the VO. We believe that the current state of the art—the Web Services paradigm, is too fragile and tangled for efficient collaboration in AEC. Grids provide the robustness but need to be made aware of the business concepts that the VO is addressing. The grid itself needs to commit to the product’s and process’s ontology thereby evolving into an ontology committed semantic grid. To do so there is a need for the generic business-object-aware extensions to grid middleware, implemented in a way that would allow grids to commit to an arbitrary ontology. These extensions are propagated to toolkits that allow hardware and software to be integrated into the grid. This is expected to be done in a European Project called inteliGrid. This paper presents its baseline, hypothesis and expected results. The project’s impact is expected to be wide; it will create knowledge, infrastructure and toolkits that will allow for a broad transition of the industry towards semantic, model based, ontology committed collaboration using the grid, rather than the Web, as the infrastructure, thus enabling the grid to become a mainstream collaboration paradigm.

1 INTRODUCTION The integration of the AEC industry and the interoperability of the hundreds of software applications supporting the design and construction of the built environment have been providing one of the most challenging environments for the application of information and communication technologies. The “islands of automation” (Hannus & Silen, 1987)

Towards engineering on the grid

297

problem has been identified by the AEC community in the late 1980s and several national and EU project have been tackling the problem since. It is interesting to read Foster’s definition of the grid (Foster, 2002) in the context of collaboration requirements of the construction industry Foster defines grid computing as “coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations…not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problemsolving…in industry. This sharing is…highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs”. This statement captures the essential requirements of collaboration in the AEC. An EU project was proposed to verify this hypothesis. It is expected to start in September 2004 and will run until February 2007 with a total funding of 3.13 million EUR. The partners in this project include University of Ljubljana (Slovenia, coordinator), TU Dresden—TUD (Germany), Polish Center for Super-computing Applications—PSNC (Poland), VTT (Finland), EPM Technology AS—EPM (Norway), Conject (Germany), Sofistik (Greece), OBERMEYER Planen+Beraten GmbH—OPB (Germany) and ESoCE NET (Italy). The home page of the project is at http://www.inteligrid.com./ 2 STATE OF THE ART This section presents the state of the art in grid computing and AEC interoperability. We believe that there is a clear convergence between the two. 2.1 Grids and semantic grids Grid is a type of parallel and distributed system that enables the sharing, selection, and aggregation of geographically distributed “autonomous” resources dynamically at runtime depending on their availability, capability, performance, cost, and users’ qualityof-service requirements. Grid computing is an innovative approach that leverages existing IT infrastructure to optimize computing resources and manage data and computing workloads. According to Gartner (Price WaterHouse Coopers, 2002), “a grid is a collection of resources owned by multiple organizations that is coordinated to allow them to solve a common problem.” Gartner further defines three commonly recognized forms of grid: – Computing grid—multiple computers to solve one application problem – Data grid—multiple storage systems to host one very large data set – Collaboration grid—multiple collaboration systems for collaborating on a common issue. Grid computing has its origins in solving computationally intensive problems. Recent developments and trends of grid computing go beyond the solving of data (petabytes) or computationally (teraflops) problems for scientists and engineers towards making grids a suitable business infrastructure for virtual organizations. Grids are increasingly viewed as services (Foster et al., 2002) aware of the business semantics. Semantic grids should

eWork and eBusisness in architecture, engineering and construction

298

provide to the grids what the semantic Web is providing to the Web—communication based on high level, meaningful entities. There are numerous related research projects in the EU, the US and beyond: The Grid Enabled Optimization and Design Search for Engineering (GEODISE) (http://www.geodise.org/) project was one of the first to explore the possibilities of the semantic grid, however, the semantics was being attached to files as metadata. True semantic-rich that would study the meaning of the information inside the files is not addressed. The myGrid (http://www.mygrid.org.uk/) project defined its architecture using the OGSA architecture but does not seem to be based on a common ontology which is what inteliGrid is aiming for. The Commodity Grid Kit (COG) (http://wwwunix.globus.org/cog/) project has similar goals to inteliGrid, but is addressing a different business sector and seems to be primarily concerned with the heterogonous data formats and not heterogonous information schema addressed in inteliGrid. Based on the review of the state of the art, semantic information as we understand it in engineering has to date not been addressed in a grid environment. This is a key contribution of this project. Also relevant to the inteliGrid project are the Collaborative Advanced Knowledge Technologies in the Grid (CoAKTinG) (www.aktors.org/coakting) and Grid-Enabled Desktop Environments (GRENADE) (http://mrccs.man.ac.uk/research/grenade) projects that address the interactive collaboration using grids. This is not targeted in inteliGrid but their open source results could be re-used in the inteliGrid demonstrations. The only grid project related to the AEC sector that we are aware of is the National Science Foundation (NSF) funded Information Infrastructure for Earthquake Research (SCEC/IT) (http://www.isi.edu/ikcap/scec-it/). The rather broad and practical goal is to “provide information technology infrastrucrure for earthquake research, including knowledge representation and reasoning, Grid technologies, digital libraries, and interactive knowledge acquisition”. World leading software companies such as Oracle, IBM, Microsoft and several software SMEs are also developing grid middleware and grid extensions to their existing software. The following are some software vendors, which could potentially make use the results (semantic extensions) of the inteliGrid project: – Oracle delivers database products and application servers. Their Oracle 10 g version is an enterprise grid version, using server consolidation and cluster computing techniques. – Avaki Corporation is a supplier of commercial grid software solutions that provide wide area access to data, compute, and application resources in a single, uniform operating environment. – Metapa supports business intelligence applications on open source, commodity technology, including the use of Lintel platforms and Metapa’s database clustering technology. – GridSystems develops and markets the InnerGrid multiplatform product that allows the application of the Grid technology to the current corporate environment. It speeds the key processes of a business converting underused resources in a virtual supercomputer.

Towards engineering on the grid

299

2.2 AEC interoperability inteliGrid addresses the interoperability needs of automotive, aerospace, shipbuilding, furniture and AEC industries. Perhaps the most demanding environment is the AEC industry. Characteristic for the AEC industry are the uniqueness of the products, the processes and the dynamic and quite improvised VO involved in the process. The items to be integrated are seldom predefined and the integrated solution is unlikely to be repeated. One stable element in this framework is the conceptual model of a building product. While buildings are different from each other, the language (and the data structures) required to describe them are believed to be stable. Both the International Organization for Standardization (ISO) and the International Alliance for Interoperability (IAI) have made a considerable investment into the building classification and building product model standards that defined the data structures required to describe any building product. Several European projects have demonstrated that by using these standards data created in one application may be used in another. The Consortium has been actively involved (coordinating, partnering) in several of these projects and has also learned from the problems that they faced. The IAI and ISO efforts, however, are not limited to the AEC industry but are targeting the whole spectrum of industries that are designing and building three dimensional material products. In spite of the extensive research in building information models, however, the industry still communicates using line drawings, files and perhaps project webs. We believe that one reason for that is that the generic IT infrastructures today are well suited for semantically poor data formats and file or document level information exchange. Semantic Web and web services technologies, built around XML have been demonstrated in research projects, such as eCONSTRUCT (http://www.econstruct.org/) and ISTforCE (http://www.istforce.com/), but their scalability in large complex industrial environments has not been tested. Building product model is defined, and IFC version 2.X is supported by key 3D modelling suites like ArchiCAD, Architectural Desktop and Microstation. They can produce a building information model (BIM) that will be used by hundreds of other applications that support the design, planning and maintenance of building products. These applications will need to read and write the building information model. Today, they do so in a variety of ways. The prevailing way is by reading and writing files in a format and schema conforming to the standard. Where to write data to and where to read it from needs to be managed by the human user each time a program is started (File...Open) or closed (File...Save as). These files may be uploaded/ downloaded to/from project webs. Again, humans are to a large extent responsible for locating the right information at the right time. Building information model databases are being developed that will replace files as container of BIM data. Several such databases are under development or even already entering the market, for example WebStep by Eurostep, EXPRESS Data Manager by EPM Technology, and IFC Model Server by SECOM, BSPro Server from Granlund etc. For software to work with these databases, specialised interfaces (APIs) or dedicated clients binding the program to a location of a particular database are needed. Again, in a multi project environment, with multiple programs being used ondemand, this may be so

eWork and eBusisness in architecture, engineering and construction

300

hard that it may effectively discourage the use of building information models. These problems are partially tackled by the generic services developed at TU Dresden (Weise et al, 2004). The suggested approach mitigates hard demands associated with product data sharing thereby allowing incremental improvement of the application of BIM in practice. Product model standards and ontologies have in parallel been developed in other industries as well. While they share common schema for the geometric information, product structure and configuration management, they specialise when it comes to information about distinct product components. The STEP standard ensures that interoperability between domain models (known as Application Protocols—AP) is possible through the integrated information resource layer, but in order to further reduce the cost of developing future APs ISO TC184 SC4 has introduced the Application Modules (AM) layer, which defines self contained Units of Functionality (UoF) that can be reused between the different models (http://step-mod.sourceforge.net/). A major initiative that has resulted in the publication of a new application protocol is PLCS (ISO10303–239). It contains many of the modules found in PDM schema (itself a subset of AP203, AP212, AP214 and AP232), with additions to support service and maintenance concepts. The PLCS data model was designed in order to provide a data model that is capable of supporting product data throughout the product lifecycle. It supports automotive, aerospace, shipbuilding, AEC and other industries. 3 THE inteliGrid PROJECT This section proceeds from visions, placing them in context, stating high levels goals and refining them into measurable, scheduled objectives. 3.1 Vision The vision of the project is to provide the industries with challenging integration and interoperability needs a flexible, secure, robust, ambient accessible, interoperable, payper-demand access to (1) information, (2) communication and (3) processing infrastructure. The idea to support virtual organizations has been central in grid protocols development computting (Foster et al., 2001), however, most practical results to date were related to a fast distributed computation and storage. The hypothesis of this project is that grid technology has the potential to provide such infrastructure. 3.2 Context—integration and interoperability in complex industries The integration of the AEC industry and the interoperability of the hundreds of software applications supporting the design and construction of the built environment have been providing one of the most challenging environments for the application of information and communication technologies. The “islands of automation” problem has been identified by the AEC community in the late 1980s and several national and EU project have been tackling the problem since. Grids are expected to be the solution to the “islands of computation” problem. Figure 1 shows what has been known since later 1980s as the “islands of automation” problem.

Towards engineering on the grid

301

Figure 1. Islands of automation (Hannus & Silen 1987). The sea and the various transports across to be replaced or incorporated by a grid. The islands in the figure are various areas which were automated at a certain time. It should be imagined that the islands are rising slowly from the water. So, for example, in the 1960s, only a few selected tasks were automated. By the 1990s large areas of engineering design, architectural design and management were automated, however, the gap between those (as well as within various peaks on the same island) still had to be bridged by various integration and interoperability technologies, such as the Drawing Interchange file format (DXF) ferry (symbolizing the exchange of drawings) or a more modern Industry Foundation Classes (IFC) gate. It is the vision of this project to replace the several different technologies used to travel between the islands, by “freezing” the sea, by replacing the sea with the grid. Grids could ensure the interoperability and collaboration platform providing that they include the key ingredient required for a complex engineering virtual organization—the support for the shared semantics (Sowa 1984, Guarino et al., 1997). It is in this area where we believe innovation and extension of the current grid architectures is required. To the end user as well as engineering software developer this will bring two major improvements. The grid infrastructure eliminates the need of knowing exact locations of information and services. They are “on the grid” not at some Uniform Re-source Identifiers (URI) or Internet Protocol (IP) address. The shared semantics powered by ontology reduces the need to know the exact structure and access paths of the data in

eWork and eBusisness in architecture, engineering and construction

302

product model databases. The result is a semantic or cognitive grid. It is generic—it gets its business semantics from an ontology that can be an arbitrary one. While the AEC industry is providing the testing environment for the project, all technologies developed will be generic and applicable in any kind of virtual organization environment and are not limited in any way to AEC. Business sectors that include long and complex supplier chains share the same interoperability problems as the AEC. They will be represented in inteliGrid—providing requirements and evaluating the end—as well as interim results through the Industry Advisory Board (IAB) and ESoCE NET. Moreover, many of the software applications to be integrated to the inteliGrid platform are of general applicability to computational intensive problems coming from other sectors as biomechanics, aerospace, shipbuilding and automotive industries. 3.3 Project goals The long term practical goal of the project is to provide complex industries such as construction, automotive and aerospace stable, co-allocated, reliable, unified, adaptive, remote, ambient accessible, interoperable, pay-per-demand access to: (1) information, (2) communication and (3) processing infrastructure and thereby provide the integration and interoperability infrastructure. This goal cannot be achieved by the project alone. But it can prepare the enablers—the true project targets—for the paradigm shift from internet and web services to the grid. The enablers are researchers, standardization bodies and the key software developers. They need a reference grid, which will be in a position to provide the strategic steering of their future developments. Current state of the art addressing these needs is based on the (semantic) Web services approach. This approach is viable in businesses with stable and long term virtual organization relations where the investment into finding a service with the Universal Description, Discovery and Integration (UDDI), learning its interface with the Web Services Description Language (WSDL) and finally creating the links with SOAP pays with the long time using of the services. In contexts where the involvement of a partner in a VO is temporal, short term, but needs to be set up quickly, a grid based approach seems more appropriate. The Figure 2 compares the two approaches. The key scientific question addressed by this project is how grid technology can be used to address the interoperability of software and services working with complex and semantically rich information.

Towards engineering on the grid

303

Figure 2. Collaboration in a tangled Web services environment with multiple private ontologies—current state of the art (above), compared to the VO based on a semantic grid platform committed to one ontology (below). In addition, the software and services need distributed processing power to crunch this information. This needs to be done in an environment characterised by some standard data structures that are undergoing a dynamic evolution. The key technological goal is to make the grid infrastructure available to the mostly small to medium enterprise (SME) companies that are providing the engineering software. The core competencies of these companies are topics like structural mechanics or 3D solid modelling and not latest trends in middleware technology. The results of the technical work will demonstrate how typical server side applications (or components of applications) can be made grid computing compatible and how the mostly client side

eWork and eBusisness in architecture, engineering and construction

304

Computer Aided Design (CAD) applications can interface with the grid. This will attract new SMEs to enhance their applications with gridcomputing capabilities, since the project will provide the necessary libraries, toolkits and guidelines. The results are shown schematically in section 5. 3.4 Innovation inteliGrid goes beyond simply grid-enabling present day applications, on present day grids. It creates an underlying fabric in the form of abstracted toolkits and tools that can be used to grid enable old applications, and more importantly to build innovative new generations of grid applications that use semantics and ontologies. It also focuses on applied research in the area of application scenarios in many areas, such as engineering, construction, aerospace, fluid dynamics etc., that take unique and unprecedented advantage of emerging semantic grid technologies.

Figure 3. Globus grid reference architecture. The white elements are part of the existing architecture. The grey ones are generic extensions to be developed and validated by the inteliGrid project. Main innovation activities are focused on extending the grid architecture with semantics and ontologies beyond current work on metadata and heterogeneous data formats. This is then verified by making vertical applications use these services. Activities include state-of-the-art studies, requirements analysis, design and prototyping of the software. As discussed earlier recent developments in the grid community extended the architecture towards the services paradigm that is a prerequisite for semantic grid. Figure 3 shows this architecture. We believe that if the grid is supposed to become an integrative element for VO, the notion of the business concepts of this VO should be an integral part of the grid. We plan to achieve this by adding an ontology layer into the grid that would allow for any grid service to know what business relevant some data or process has. The layer would be made available to other functionality through an ontology server. Particularly important is this service to the database services of the grid, however, several

Towards engineering on the grid

305

ftmctions of the grid such as Monitoring and Discovery Service—MDS (http://www.globus.org/mds) and Globus Resource Allocation Manager—GRAM (http://www.unix.globus.org/developer/resource-management.html) could work more intelligently, if they are aware of the business context. Interoperability in AEC today, at best relies on the management of IFC files. Attempts to use true IFC databases are mostly academic. An exception is IFC data managed by EPM for the Singapore Building Authority. This is a multi-user environment for validating building plans against national building regulations (EPM Technology AS 2001). EPM is also managing a Product Life Cycle Support (PLCS) implementation for the Norwegian navy, which will handle all lifecycle data related to the frigates in their fleet. The implementation uses the concept of DEX (Data Exchange Set) developed in PLCS to allow applications to access subsets of the PLCS data model. In effect these are similar to STEP conformance classes and allow different applications to access the data they are interested in. Merging and partial extraction of the data to/from the PLCS data model, as well as access control is managed by EPM. The PLCS implementation (http://www.posccaesar.org/) also makes use of reference data that complies to ISO 15926 in order to further constrain the data population and to reduce the problem of data redundancy. File-based environments are fragile and depend on a single server that provides such crucial fimctions as information and process management for a complex project. inteliGrid proposes to use the grid as a robust, scalable, safe infrastructure for the industry. It would allow seamless integration of software committing to any product data standards and focus the developers into the ftmctionality and not data exchange or interfacing with this or that information server. The grid is the place for the semantically rich data. Currently there are a few companies providing ASP services and project webs to engineering communities that allow collaboration and information sharing. The grid will extend this concept towards true resource sharing and on-demand resource renting. This will allow for new business models to be developed as well as the rethinking of the information technology infrastructures in the industry. Grids could provide the necessary robustness as well as security (Welch et al, 2003) (through the X.509 mechanism) that would make outsourcing the IT infrastructure a more realistic option than today when they have to rely on a multitude of chaotically interwoven services. This project is introducing two major generic improvements visible to the end user as well as the application developer: – The grid infrastructure eliminates the need of knowing exact locations of semantically rich data and complex problem solving services. They are “on the grid”. – The ontology reduces the need to know the exact structure and access paths of the data in product model databases. They can be accesses by using an engineering ontology as opposed object names and record keys.

eWork and eBusisness in architecture, engineering and construction

306

4 TOWARDS A STANDARD ENGINEERING GRID 4.1 Grid standards Grid (Services) Computing is based on an open set of standards and protocols (i.e., OGSA) that enable communication across heterogeneous, geographically dispersed IT environments. The current trend is to produce a broader set of standards that cover all aspects of Grid technologies (computational, data storage, networking and web services). This effort is articulated through the Global Grid Forum (GGF). The focus of the standardization contribution of this project to the global grid movement will be the proposal of semantic extensions to the OGSA specification. Currently OGSA’s ontology is technical—it speaks of services, protocols, processes, computers etc. We propose to build the semantic deep into the core of the grid standards so that any grid related service or protocol can have a meaningful “business” role. Our current idea is to allow for an arbitrary ontology, specified in one of the well established ontology languages, become part of the very fabric of the grid. More specific plan of the inteliGrid partners is to participate actively in two of the working/research groups of the GGF: – Grid Scheduling Ontology Working Group (proposed), and – Semantic Grid Research Group (SEM-GRD) (http://www.semanticgrid.org/GGF/). The roles of these groups are to produce ontology of Grid accompanied by a set of documents describing the ontology and the tools/libraries used to create the ontology and to make use of the ontology later. The ontology created will provide the machine “processable” meaning of scheduling terms and conditions that is needed to negotiate service level agreements between usually heterogeneous systems operated at different independent sites. The working group will define usage and hierarchy of terms from the Grid Scheduling Dictionary thus helping to understand these terms and enable tool builders to incorporate the ontology into their tools. The ontology will overcome the shortcomings of a dictionary allowing classification of schedulers, reasoning about schedulers or mapping semantics of different scheduling systems for example. Using the ontology generated by the working group when designing and implementing the next generation of GRAM and their corresponding Grid services may further lead to ontologydriven systems. The goal of the SEM-GRD is to realise the added value of Semantic Web technologies for Grid users and developers. It provides a forum to track Semantic Web community activities and advise the Grid community on the application of Semantic Web technologies in Grid applications and infrastructure, to identify case studies and share good practice. The partners will propose topic oriented chapters of the GGF. GGF is now organised either by geographic location or grid related technical topic, but not according to the potential branch of industry having specific requirements to the grid. The proposed aec.gridforum.org would focus on AEC virtual organizations, semantics and ontologies for grids.

Towards engineering on the grid

307

4.2 Interoperability standards and ontologies AEC interoperability standards, most notably the IAIIFC aka ISO PAS 16739 IFC, aecXML (http://www.iai-na.org/aecxml/mission.php) , bcXML (http://www.econstruct.org/), ISO 10303 STEP and the related STEP/SDAI (ISO 1994) protocols are at an early stage of transition from research environments towards industrial use. An adequate infrastructure, on which software that would support these standards would run comfortably and smoothly, does not exist. We intend to provide it in the inteliGrid project. It will, in this way, make a significant contribution to the introduction of the most important family of standards that the AEC industry has developed over the last 20 years. At a recent workshop at Corm’te Europeen de Normalisation (CEN) five areas of specifications (CWAs—CEN Workshop Agreements) that may lead to CEN standardisation, were identified (resulting, in part, from the ICCI project involving three inteliGrid partners): 1 European eConstruction Framework. This framework will model on a high abstraction level the world of “eConstruction” with all relevant dimensions. 2 European eConstruction Architecture. A common, logical architecture fulfilling the EeF incorporating vital components like: schemas, taxonomies, APIs and software. 3 European eConstruction Meta-Schema (EeM). 4 European eConstruction Ontology (EeO). 5 European eConstruction Software Toolset (EeS). inteliGrid’s reference grid architecture directly addresses the needs of #1 and #2. Through the development of construction ontology in WP3 it is directly addressing the needs of #4: – inteliGrid also has an ambition to evolve the dated, client-server, STEP physical file based ISO 10303–22 SDAI into a modern, grid enabled information access interface to product model data. – Partners of inteliGrid will continue to be involved with IAI-IFC development. TUD, VTT, OPB and EPM are actively involved in the IFC development process. – inteliGrid will contribute to the harmonisation of competing ontologies currently available in the construction sector, particularly in ironing out the differences between the implicit ontology’s of IAIIFC and those developed under the ISO 12006–2 and the ISO 12006–3 framework standards. It is there three standards that could provide the baselines for a common ontology for AEC. – inteliGrid will contribute to the development of an explicit ontology of the AEC components of the IAI-IFC.

5 DRAFTARCHITECTURE In Figure 4, the users are using the applications. These applications need information and ftmctionality from the outside of the user’s workstation, from the grid. The applications therefore have a workstation component and the grid based component. The communication media between the workstation and the grid is the

eWork and eBusisness in architecture, engineering and construction

308

Internet and the workstation applications, their grid based counterparts, as well as the grid only services are connected to the grid with a series of interfaces. At the very bottom there are numerous computers on which these “grid side” services run. Workstations would typically not know on which machine the service is running. Computationally intensive services would run on several in parallel, big databases would be spread across several machines. Simple services would have redundant backups in case of computer or network failures. Any prototyping should therefore develop these components that together form a semantic collaboration grid: – grid enabled workstation applications (the first three from the left) that connect to a grid through a – specialised semantic grid adapter for each application. This adapter talks to the workstation-side semantic grid client common to all applications on a workstation. Over the internet, this client connects to – server side semantic grid server. It would run on machines providing grid enabled services – semantic grid adapter will be used by services that are to made grid enabled – specialised core servers, such as the product database and an ontology server. This software may not have a workstation component other than some administration interface.

Figure 4. Draft architecture of inteliGrid. The grid, enhanced with generic product data and ontology services provides the collaboration and interoperability platform for problem solving.

Towards engineering on the grid

309

6 DISCUSSION In spite of successful pilots, the AEC industry lacks a robust collaboration infrastructure. Grids are the latest hyped technology that promises the solution to this decades old problem allowing both the researchers as well as the industry to capitalize on the development in standards of the past decades. A grid is a natural transition path for the project webs and application service providers. In this paper we have not been mentioning a very clear potential that the grid has for the providers of complex numerical and modelling software that is truly hungry for processing power and gigaflop computers; the usefulness of those in solving complex engineering problems is obvious. Research in the field of grids in AEC is just starting. An EU project has been proposed, AEC partners have been involved in the preparation of a Grid integrated project. There is at least one national grid related project (in Slovenia— http://www.gridforum.si/) seriously is focusing on the AEC aspects of the grid. However, grid research in AEC is still rather new. The vision shared by the authors of this paper is that the AEC community should work towards a single AEC grid in which various services and software could be plugged in and not repeat the mistakes of the various “integration” projects that developed their own collaboration infrastructures from scratch. This paper is therefore proposing the establishing of aec.gridforum, to coordinate and harmonize grid efforts in AEC as well as to show the general grid community, that to support, with grid technology, virtual organizations of a particular domain, domain specific solutions, particularly those related to domain ontologies, should be built into the fabric of the grid. ACKNOWLEDGEMENT This paper is based on the inteliGrid Project Proposal and its subsequent Description of the work. Through their contribution to the definition of the project, these colleagues also contributed to this pa per (in alphabetical order): T.CerovTiek, U.Forgber, A.Gehre, U.Forgberger, J.Hyvarinen, J.Mitchell, B. Protopsaltis, R.Santoro, R.Scherer, V.Stankovski, K.Tonn. As co-authors, only those are listed that made a significant contribution to the delta between this paper and its baseline documents. REFERENCES EPM Technology A.S., 2001. Singahpore leads the World in Automated Building Plan Approval, http://www.epmtech.jotne.com/newsletter/ew101/singapore.html Foster, I, Kesselman, C., Nick, J. & Tuecke, S., 2002. The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. http://www.globus.org/research/papers/ogsa.pdf Foster, I, Kesselman, C. & Tuecke, S., (2001. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of High Performance Computing Applications, 15(3) 200– 222. Foster, I. 2002. What is the Grid? A Three Point Checklist. http://wwwfp.mcs.anl.gov/~foster/articles/WhatIs TheGrid.pdf

eWork and eBusisness in architecture, engineering and construction

310

Guarino, N., Borgo, S. & Masolo, C. 1997. Logical modeling of product knowledge: towards a well-founded semantics for STEP. In Proceedings of the European Conference on Product Data Technology, Sophia Antipolis, France. Hannus, M. & Silén, P., 1987. (updated by Hannus, M. 2002) Islands of Automation. http://cic.vtt.fi/hannus/islands.html ISO 1994. DIS 10303–22. Part 22: Standard Data Access Interface. Price WaterHouse Coopers, 2002. Powerful technology trends continue despite downturn. PWC Global Technology Center, Menlo Park, CA. Sowa, J.F., 1984. Conceptual Structures: Information Processing in Mind and Machine., AddisonWesley, Reading, MA. Weise, M., Katranuschkov, P &, Scherer, R., 2004. Generic Services for the Support of Evolving Building Model Data. In Proceedings of the Xth International Conference on Computing in Civil and Building Engineering, Weimar, Germany, June 02–04, 2004. Welch, V., Siebenlist, F., Foster, I., Bresnahan, J., Czajkowski, K., Gawor, J., Kesselman, C., Meder, S., Pearlman, L. & Tuecke, S., 2003. Security for Grid Services. In Proceedings of the 12th International Symposium on High Performance Distributed Computing (HPDC-12), IEEE Press, June 2003.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Managing long transactions in model server based collaboration M.Weise, P.Katranuschkov & R.J.Scherer Institute of Construction Informatics, TU Dresden, Germany ABSTRACT: We propose a novel approach for project collaboration based on product data technology, the C/S paradigm and the concept of long transactions. It provides an open server-based solution that can tackle problems caused by the heterogeneity of ICT environments in AEC and does not presume neither require tightly integrated application systems. The essence of the suggested approach is in the coherent use of a set of generic services supporting the sequence of well-identified data modification processes. These services comprise partial model extraction, model mapping, model matching (including model comparison and model reintegration) and model merging. In this paper we focus specifically on problems related to the reintegration of changed model subsets. We show on theoretical level why generic model comparison cannot fully guarantee error-free results for the reintegration of changed model data and discuss the use of model subsets and their impact on project data sharing. At the end we describe envisaged possibilities to apply the developed concepts to the IFC project model and give a critical discussion for its application in AEC practice.

1 INTRODUCTION Today it is widely accepted that efficient project collaboration can be best accomplished using product data technology as basis (Eastman 1999). However, there are still a number of problems to be solved. The existing heterogeneity of tools and systems in construction IT, and especially the variety of data models used in the different stages of the design process, strongly limit the successful application of PDT in practice. Undertaken standardisation efforts, whilst principally successful, cannot fully overcome this problem. It seems that additional model mappings will always be required (Turk 2001). Integrated environments that have been demonstrated by a number of research projects in the last decade are yet of little acceptance because they typically require wellharmonised applications, only capable to process agreed model data to a fine granularity level. Scaling up such environments to the full set of practical use cases in computerintegrated construction is unlikely to be achieved due to the extreme increase of complexity with regard to modelling representations, model mappings and consistency (Amor & Faraj 2001). Obviously, solutions should be sought by other ways.

eWork and eBusisness in architecture, engineering and construction

312

We propose a novel approach to the realisation of a promising collaboration scenario that may be practically achieved on short term: check-out/check-in of partial model data provided by a central product data repository maintained by a model server. In AEC/FM, and in fact in most other engineering domains as well, ‘check-out/checkin’ of model data is a typical long transaction, comprising a set of well identified data modification processes. Ideally, such long transactions should happen concurrently, on (disjoint) subsets of the shared model data. Consequently, check-in of concurrently changed model subsets leads to model matching and model merging problems that have to be adequately tackled. An important aspect here is the capability to adequately deal with model subsets (aka partial model) which has been addressed in several research efforts (Lockley & Augenbroe 2000, Adachi 2002). However, in all known approaches the final check-in is either poorly supported (the reintegration of the data into the shared model is left almost entirely to the application tools which typically results in a tedious, interactive process), or its complexity is ignored (assuming an ideally harmonised environment where no data loss happens due to mappings between semantically and structurally different representations). In practice data mapping and all subsequent user modifications most often happen within a ‘black-box’ application (CAD, analysis/simulation tool…) producing unknown changes with regard to the overall management system. As there are a lot of different black-box applications users might need to use, an objective of utmost importance is the development of generalised data management methods that (1) are applicable to different product models, and (2) can be flexibly assembled and tailored to support specific process sequences and preferences derived from the general check-out/ check-in procedure outlined above. In this paper we describe how the problems related to the use of such black-box applications can be successfully tackled. Suggested is an approach combining partial model check-out based on GMSD, the Generalised Model Subset Definition Schema developed by the authors and described in (Weise et al. 2003), and a generic method for comparing changed model data only on the basis of the underlying model schema (Weise et al. 2004). We show how the information defined by the GMSD schema can be used for comparing changed data and how the identified separate processes can be inter-linked to improve the result. Special attention is given to the reintegration of the changed partial model data which is, beside model merging and consistency control, one of the most challenging tasks towards the achievement of model-based collaboration. The developed services have been based on the broadly accepted EXPRESS modelling language (ISO 10303–11 1994). Therefore they can be verified and used with the IFC project model and all legacy applications supporting IFC-based data exchange. 2 SUGGESTED APPROACH Whilst the need for open, scalable and standardised ICT environments for AEC collaboration is generally recognised, such environments are not easy to achieve in the highly fragmented landscape of the construction industry. In order to apply product data technology in practical work we have to acknowledge that:

Managing long transactions in model

313

1. The achievement of data integration requires sophisticated model mappings that in turn may produce additional data conflicts or even data loss. 2. Engineering work requires long transactions and these transactions must happen concurrently Hence, the goal should be to provide pragmatic methods which may not guarantee full consistency at any time but which should support the users to regain consistent model states. 3. Standards enabling collaborative work have not yet fully penetrated design and construction practice. File-based data exchange of (partially) standardised model data is the current, quite insufficient common denominator with regard to data sharing. Therefore, in the development of collaboration approaches problems of ‘imperfect’ data exchange scenarios need to be tackled as well. 4. The road towards comprehensive life cycle data sharing will include a number of incremental steps seeking to find the optimal balance between fully automated consistent solutions for limited subsets of the design data and adequate interactive functions to fill in the gaps. Consequently, an approach allowing to alleviate hard demands associated with the problems of data sharing is required. Our approach is based on the conviction that full integration and consistency of the evolving design data are not needed continuously but only at specific coordination points, reasonably selected by the design team. We do not try to create a closed ideal world but provide an open solution which allows to reduce data loss, improve data sharing quality and reach a practically adequate degree of consistency. The developed concept does not promise a perfect environment providing faultless data integrity. Instead, the strategy is to mitigate the requirements to the involved engineering applications, reduce data loss caused by data mapping and other data conflicts, and at the same time take into account practical deficiencies in current data models and their software implementations. The envisaged principal application scenario is based on the concept of long transactions allowing off-line modifications and, in order to support parallel work, involving versioning and merging of concurrently changed data. This is achieved with the help of four key generic services as follows: — extraction of model subsets that are of interest for a specific design task, — mapping of the model data to support different modelling representations, — matching of two successive model versions to help recognise properly the latest modified data, and — merging of concurrently made data changes. We assume a common modelling paradigm and a commonly agreed (standardised) data model to represent the data to be shared. Taking into account current practices and trends, the developed services are based on the broadly acknowledged EXPRESS modelling language and can therefore be used with a lot of existing data models, such as an IFC project model of any version and a like. Whilst there are many different use cases where these services can be applied, they can all be derived from the principal scenario shown on Fig. 1 below. It starts at time point ti with the consistent shared model version Mi based on the product data model M (defining the data that have to be shared), and proceeds until the next coordination point ti+c is reached.

eWork and eBusisness in architecture, engineering and construction

314

The data processing sequence for a single designer is comprised of the following six steps: 1. Model subset definition and subsequent extraction of the needed model data from Mi to a model subset Msi, which can be expressed as Msi=createSubset (Mi, subsetDef (Mi)). 2. Mapping of the model subset Msi to the domain model Si representing an instantiation of the domain data model S, i.e. Si=map (Msi, mappingDef (M, S)).

Figure 1. Schematic presentation of the principal application scenario for model server based collaboration. 3. Modification of Si to Si+1 by the user via some legacy application which can be expressed abstractly as Si+1=userModify (Si, useApplication (A, Si). 4. Backward mapping of Si+1 to Msi+1, i.e. Msi+1=map (Si+1, mappingDef (S, M)). 5. Model matching of Msi+1 and Msi+1 including object identification, comparison and evaluation resulting in the found differences ∆Msi+1,i, i.e. ∆Msi+1,i=match (Msi, Msi+1). 6. Reintegration of ∆Msi+1 in Mi resulting in Mi+1, i.e. Mi+1=reintegrate (Mi, ∆Msi+1,i). The final consistent model Mi+1 can then be merged with the divergent design data of the other designers (modified in parallel using the same procedure) at the coordination time point ti+c to obtain a new stable model state Mi+c. This can be expressed abstractly by Mi+c=merge (Mi+1, Mi+2,…, Mi+k), with k=the number of concurrently changed checked out models. If a standardised data model that can be processed by the involved engineering applications is used, as e.g. IFC, then the model mapping shown in Fig. 1 will not be necessary. Similarly, if all common data from Mi can be processed by the used application(s), subset creation can be skipped. The reintegration of changed data, specifically focused in this paper, is always necessary in all application scenarios dealing with model subsets. It depends directly on the result of the previous steps, especially on the quality of model comparison performed by the matching operation. Additionally, the used model subset is needed to be able to identify deleted model data. In order to evaluate the process of reintegration we will shortly characterise the model subset extraction and the model matching methods.

Managing long transactions in model

315

3 MODEL SUBSET EXTRACTION The use of model subsets in the data modification processes has several advantages. Beside reducing the quantity of exchanged data, the most notable reason is to specify the model subset which can be properly managed by the requesting application. In the case of

Figure 2. Applying model subset extraction to remove unchanged data before matching. the IFC model which covers several design domains, an application for architectural design can hardly be expected to manage all information related to HVAC design, albeit contained in the IFC model. This problem is well known to the Implementation Support Group (ISG) of the IAI and is semantically tackled by model subset agreements, the so called view definitions. However, we still miss a sufficient server manageable model subset definition. To be used in the envisaged scenario, a model subset should be (1) easily definable with as few as possible statements, (2) completely described within a single service request and (3) usable for reintegration of changed data by allowing elimination of mismanaged or unmodified data sets. To serve these requirements on adequate scale we have developed a Generalised Model Subset Deflnition schema (GMSD) which can be used as schematically shown in Fig. 2. The first createSubset() operation generates the model subset Msi which is then modified by some design application to Msi+1. However, in the case of using a STEP physical file mandatory attributes have to be written to Msi even if not defined by the model subset request. This results in superfluous and often mismanaged information. Removing such attributes can be achieved by applying the same createSubset() operation to Msi+1 too. The model subset can then be further advantageously reduced by removing unmodified data. For that purpose, a new subset extraction has to be specified and applied to both Msi and Msi+1*

eWork and eBusisness in architecture, engineering and construction

316

so that the resulting model subsets and are processible by the following model matching service. More details on GMSD are provided in (Weise et al. 2003). 4 MODEL MATCHING Model matching can be divided into the comparison of (externally) modified design data and, if a model subset is used, its reintegration into the complete set of design data. The principle of a highly reusable generic comparison of object oriented models is based on the premise that there are corresponding data object instances of the same model schema which can be compared on attribute level. However, for real practice, different from a pure academic approach, we have to consider that (1) not all objects can be uniquely identified by a kind of a key value, (2) a structural difference in the data does not always imply a change in their semantic meaning, (3) eventual data loss caused by model mapping may emerge on object and attribute level and (4) errors from the used application may result in replacement of valid data (such as wrongly set IDs, replacements by default values etc.). As indicated in the previous section, the problems (3) and (4) can be tackled by the model subset definition. Problem (2) can be tackled by using a ‘normalising’ model mapping which can help reduce the variations of the data structures representing one and the same semantic meaning. Hence, our proposed model comparison method has to deal basically with the problem of object identification. Unfortunately, this problem is theoretically not unambiguously solvable under the abovementioned real world conditions. Therefore we suggest an algorithm that provides a simple scalable way for finding corresponding data objects. Its essence is in the iterative generation of object pairs by evaluation of equivalent references of already validated object pairs. The result of the suggested algorithm is affected by the underlying data structure (particularly the percentage of available object identifiers), the amount and kind of data changes and the occurring variations of the data structure representing the same semantic meaning. Thus, it cannot fully guarantee that all corresponding objects will be found or properly established for any arbitrary practical situation. The results may also include multiple corresponding objects in some of the cases where a single match would be the proper solution. Finally, since the algorithm is based on pure examination of the data structure (without involvement of any engineering semantics), the model comparison will always find all data changes caused by allowed variations in the representation of the same semantics (e.g. different geometry description of the same physical position in IFC). However, in spite of these deficiencies, the suggested algorithm provides a ‘95% correct’ solution in most practical situations, showing a very satisfactory performance, adequate for online processing. It overcomes the complexity involved in the treatment of the ‘most general’ matching case and, if supplemented with a suitable interactive procedure to fill in the gaps and adjust the results, can provide an error-free model comparison that fulfils the set requirements and verifies the rationale of the approach.

Managing long transactions in model

317

5 REINTEGRATION OF CHANGED MODEL SUBSETS If model subsets are used, as shown in the discussed principal application scenario, the reintegration of changed data becomes necessary. As discussed in section 3 above a model subset is created by removing data objects, cutting or reducing references, filtering attributes etc. Reintegration means to invert the process of model subset extraction, i.e. to add removed data objects, restore cut or reduced references and re-create the attributes that have been filtered out. In our approach it is heavily based on the model subset definition achieved via GMSD and on the results of the model comparison. 5.1 The reintegration process The principal alignment of the reintegration process in the overall approach is illustrated on Fig. 3. At first, by applying a GMSD-based createSubset( ) operation to a given model version some objects and attributes will be removed. For object O1 this results in a new version OS1 in which the simple reference ‘a’ is removed and the aggregated reference ‘b’ is downsized by one element. This object is then modified externally by some application to OS2 which differs from OS1 in the aggregated reference ‘b’, downsized by another element, and the simple references ‘c’ and ‘d’. The reintegration (which is the second part of the shown match( ) operation) adds all objects and attributes from O1 that have been removed according to the model subset definition. In this particular case, this will recreate the cut/downsized references ‘a’ and ‘b’. Additionally, all references from unselected to selected data objects must be recreated too, as shown for the ‘black’ object in Fig. 3, using an arrow to denote its reference to O1. Whilst this procedure is pretty clear and is more or less the same in all different scenarios, there are various detailed problems that need to be dealt with. They are shortly outlined in the following subsections. 5.2 Model comparison problems Most critical for the formal reintegration of changed data are wrongly established object pairs leading to an

Figure 3. Reintegration of model subsets.

eWork and eBusisness in architecture, engineering and construction

318

incorrect recreation of attributes. If OS2 is not based on O1 the cut and downsized references of OS1 will be assigned to a wrong successor and hence violate the originally intended meaning. It can be argued that shared significant, high-level data objects, such as instances of IfcBuildingElement from the IFC model, can be uniquely identified and that less important data objects, such as IfcPoint, are mostly used with the complete set of attributes. However, on theoretical level we cannot assume such implicit knowledge of the semantics of the model. Therefore, the reintegration of changed model subsets has to be supervised by the user to compensate missing object identifiers. For the formal step of reintegration this can be done by evaluating established object pairs and found data changes, which can be limited to data objects where cut references or removed attributes shall be re-established or added. Generally, this step represents additional user interactions which are caused by insufficiencies of the used data exchange scenario and the data handling in the participating applications. The amount of this additional work depends on several criteria such as the percentage of uniquely identifiable data objects, the quality of the data produced by the used application, and the selected model subsets for design modifications, i.e. the number of objects which have to be reintegrated. 5.3 Structural problems The described reintegration scenario is limited to object pairs in 1:1 relationships which cannot be guaranteed by the suggested comparison algorithm. If needed, it can be enforced by applying an appropriate post-processing of ‘assumed’ object pairs, applying additional criteria to reduce the cardinality. However, for tracking the design history it is important to allow n:m relationships or change of object types as well. Such cases can be tackled by applying some additional user interactions, mostly needed to resolve eventual ambiguities. 1:m version relationships This case occurs if an old object is associated to several new objects. The reintegration itself can be performed as shown in Fig. 3 by duplicating all removed attributes for all new (corresponding) objects. Consequently, in the discussed example the attributes ‘a’ and ‘b’ wills be re-established for both objects OS2 and OS2′, as shown on Fig. 4 above.

Managing long transactions in model

319

Figure 4. Problems in the case of 1:m relationship. For simple attributes like INTEGER, FLOAT or STRING this will work without structural problems if not further constrained by some uniqueness rule (which is normally required for attributes representing designated object identifiers). References are principally treated in the same way, but they are often constrained by inverse relationships, leading to a violation of the allowed cardinality. This is the case, too, if a reference to the changed object has to be recreated, because for m new objects there are m options to set the reference. This problem is shown on Fig. 4 for the ‘dark’ object which can either point to OS2 or OS2′ but not to both. In such cases an additional decision by the user is necessary to resolve the structural conflict. Alternatively, to reduce such user interactions, some further strategies for automatic suggestions can be envisaged, for instance based on least object changes. If a duplication of references can be done without structural conflicts, it leads to shared data objects, i.e. an object will be referenced by more than one object, and consequently will destroy the tree structure of an existing reference tree. However, reference trees are beneficial in the treatment of model subsets. Including a reference tree in a model subset leads to a smaller number of cut references. Moreover, data changes are locally limited and usually do not implicitly affect other parts of the model. Thus, whilst the sharing of object references is a powerful modelling concept, it should be used predominantly for uniquely identifiable objects. Otherwise, the data will be much more sensitive to design changes.

eWork and eBusisness in architecture, engineering and construction

320

n:1 version relationships This case occurs if several old objects are associated to one new object. Here the reintegration as shown in Fig. 3 cannot be performed, since n options can be found for each attribute which has to be recreated. This case requires additional user interactions to decide about possible options—either to reduce the n:1 relationship to 1:1, or the recreation of single attributes. In the example given on Fig. 5 the user has to decide about the attributes ‘a’ and ‘b’, i.e. whether they shall be recreated from OS1, from KS1 or from a mixture of both. Less problematic are references to the objects. Formally, all removed references to OS1 and KS1 can be moved to MS2, the single new object representing the successor (new object version) for both. This can be done without structural conflicts, if not restricted by constraints of inverse relationships which consequently will be defined for MS2. Change of the object type in a version relationship This case occurs when corresponding objects are of different types. The reintegration as shown in Fig. 3 can be performed for all commonly used attributes on the basis of the first common object definition in the inheritance hierarchy of both object types. This is shown on Fig. 6, where both objects use the attributes ‘a’, ‘b’ and ‘c’. However, the attribute ‘d’ of OS1 cannot be represented using the object type of OS2. Consequently, the data stored by ‘d’ will be lost. Additionally, a problem may occur when trying to recreate references originally pointing to O1, because such references may be restricted to types of OS1 and would therefore not be allowed for the more abstract type of OS2. In such cases the reference cannot be recreated. Moreover, this may lead to further problems e.g. when the reference is mandatory and therefore may not be removed. Again, this requires additional user interactions to decide about possible options—either to change the object type, or to adjust the troubling reference. Using a more abstract object type for domainspecific design changes is explicitly supported by the GMSD schema but it looks slightly different than shown on Fig. 6. In principle, an object can be changed to a type defined higher in its inheritance hierarchy in order to manage more abstract and less complex data objects, if this is sufficient for its further use. Consequently, to avoid data loss for the richer object definition a transformation to the original type will be necessary to reintegrate design changes of this object.

Managing long transactions in model

321

Figure 5. Problems in the case of n:1 relationship.

Figure 6. Problems in the case of changing the object type. However, in that case the casting of object types occurs between O1 and OS1, and not between OS1 and OS2 as shown in Fig. 6. Thus it can be restored without problems when creating O2. As it can be imagined, a mixture of these structural problems is also possible. Their superposition definitely requires further user interactions but this can be additionally utilised for a refined strategy of automatic suggestions for conflict resolution.

eWork and eBusisness in architecture, engineering and construction

322

5.4 Semantic problems Even in the restricted reintegration scenario shown on Fig. 3 full consistency of the data cannot be guaranteed solely by generic services because, in addition to the outlined structural problems, we have to deal with semantic conflicts requiring domain knowledge for their detection and resolution. Basically, a semantic conflict occurs when changes made to a model subset require a change of the remaining part of the model data in order to achieve a consistent model state. Semantic conflicts are a typical (unwanted) result by the work with model subsets which has to be tackled by the involved designers and normally requires further reviews, additional design decisions, recalculations and so on. From the viewpoint of our approach most critical and time consuming are rearrangements of the object structure without changing the semantic meaning, such as changed units and coordinate systems. If such changes implicitly affect the remaining part of the model data, an adjustment of a large number of data objects may be necessary without requiring additional design decisions of any designer. For example, if a globally used length measure is changed from meter to millimetre, a change of all attributes using a length measure is necessary. Here, only a multiplier has to be applied, but such automatic updates are not always so simple and clear. In general, additional constraint definitions will be needed to help detect such semantic conflicts. However, in current practical data model specifications such definitions are mostly limited to simple rules (like restrictions of cardinality or uniqueness of values). Therefore data consistency must finally be evaluated by the involved designers during the matching and especially the merging processes, which is not further discussed in this paper. 6 VALIDATION The theoretical approach outlined in the previous sections is being validated for several available product data models. Most comprehensive checking has been done for the IFC model due to its broadest acceptance, its overarching multi-domain scope (making model subsets an important issue), and the large number of IFC-compliant applications. As already mentioned, the result of applying the suggested services heavily depends on the underlying model definitions. They are shortly addressed below, before discussing drawn observations. 6.1 Evaluation of the IFC model from the viewpoint of model matching Concentrating on aspects of using model subsets and its later reintegration into the original source model, the following concepts of the IFC model definition have to be mentioned: – The layer concept and the respectively applied ‘ladder principle’ for references separates commonly used data from domain specific data. It makes it easy to define domain specific model subsets and finally leads to a smaller number of cut references when working with such subsets.

Managing long transactions in model

323

– Basic modelling concepts, such as defining the object geometry, location, material properties and so on are reused by inheritance throughout the whole model definition. Therefore, all participating applications will have a common understanding of these concepts and the suggested use of more abstract objects can be applied. – The IFC model globally defines the used measures and the coordinate system for object placement. The concept of relative placement makes the IFC model more sensitive to changes of model subsets w.r.t. model consistency. – In many cases there exists a large variety for describing the same semantic meaning. This makes the model vulnerable to semantic conflicts. – Not all IFC objects can be uniquely identified (via an object ID). Observations of currently available IFC data sets have shown that the percentage of identifiable objects on instance level is typically below 5%. – Starting from identifiable objects a reference tree can be created where many of the unidentifiable objects can be unambiguously allocated. However, there are several examples of shared objects without identifier where this procedure cannot be applied. This is not at all an ideal situation for the generic model comparison algorithm. – The IFC model provides the possibility to attach individual, i.e. not standardised data by using ‘property set’ objects. Consequently, sophisticated model subset definitions will be needed to restrict requested data to the manageable ‘property set’ objects. A comprehensive description of the IFC model can be found in Wix and Liebich (2001). 6.2 Practical use of the IFC model To work with practical and real size model data we make use of available IFC applications. Thus, we are limited to file based data exchange according to ISO 10303– 21, which provides no adequate support for partial model exchange. However, we can use a procedure which generates an IFC file containing the requested model subset and all additionally required data (i.e. mandatory attributes) to formally fulfil the ISO 10303–21 specification. Consequently, the changed data has to be processed by the same GMSD request removing such ‘added’ attributes in order to work with the correct model subset that was originally intended to use. This will be necessary for instance for the GloballD attribute of IfcRelationship objects, which are mandatory but not managed by most known applications, i.e. they are newly generated for each IFC export. Since relationship objects can be seen as ‘primary’ objects too, e.g. for the structural analysis domain, and because of the fact that they will typically contain a lot of cut references when using model subsets, the tracking of the data will be destroyed if identifiers of these objects are not managed correctly. If newly created GloballD attributes can be ignored, corresponding IfcRelationship objects can be found by the generic model comparison algorithm and thus can be applied for the model subset approach. To cope with such problems we have applied model subset definitions expressing the capability of the used architectural design application, namely Graphisoft’s ArchiCAD. Additionally, we have removed different object types, such as windows or doors to deal with cut references.

eWork and eBusisness in architecture, engineering and construction

324

6.3 Evaluation of the developed concept Successful data reintegration depends on the results of the model comparison, and especially on the correct identification of corresponding objects. As discussed in Weise et al. (2004), the test results for deliberately made changes were mostly very good, even when dealing with a loss of identifiers leading to only 0,1% of uniquely identifiable objects. However, for real changes in large models in the addressed long transactions the comparison algorithm may not compensate so well the heavy loss of object identifiers which can significantly downgrade the result. The performed tests showed that objects that could not be properly recognised as ‘changed’ were mostly classified as ‘new’ thereby leading, cascadingly, to the same decision for objects referentially dependent on them. However, for the IFC data structure propagation of this effect seems to remain on a limited scale because unidentifiable objects are mostly used within a reference tree, i.e. they are not independently shared. Moreover, for practical use of the IFC model cutting of references will be mainly necessary for objects which can be identified with high reliability. In contrast, objects that are not identifiable with certainty will mostly be used with all attributes which requires no recreation of removed data. Thus, the probability of data loss or wrongly reintegrated data appears to be generally tolerable. Most critical seem to be semantic conflicts caused by changes of measures and shared coordinate systems. Even so, we can conclude that IFC provides a good basis for true database transactions but respective user friendly services are yet to be developed. Such developments can be supported by the suggested novel approach presented in this paper. ACKNOWLEDGEMENTS The support of the German Research Foundation (DFG), and the involvement of FZK (Karlsruhe) in the testing of the developed services are herewith gratefully acknowledged. REFERENCES Amor, R. & Faraj, I. 2001: Misconceptions about Integrated Project Databases. ITcon Vol. 6, available from: http://itcon.Org/2001/5/ Adachi, Y. 2002. Overview of Partial Model Query Language. VTT Building and Transport / SECOM Co. Ltd., Intelligent Systems Lab., VTT Report VTT-TEC-ADA-12, available from: http://cic.vtt.fi/projects/ifcsvr/tec/VTT-TEC-ADA-12.pdf Eastman, C.M. 1999. Building Product Models: Computer Environments Supporting Design and Construction. CRC Press, Boca Raton, Florida. ISO 10303-11 IS 1994. /Cor.1:1999/Industrial Automation Systems and Integration—Product Data Representation and Exchange—Part 11: Description Methods: The EXPRESS Language Reference Manual, International Organisation for Standardisation, ISO TC 184/SC4, Geneva. Lockley, S. & Augenbroe, G. 2000. Data Integration with Partial Exchange, Proc. of International Conference on Construction Information Technology, INCITE 2000, Hong Kong, pp 277–291.

Managing long transactions in model

325

Turk, Z. 2001. Phenomenological Foundations of Conceptual Product Modelling in AEC. International Journal of AI in Engineering, Vol. 15, pages 83–92. Weise, M., Katranuschkov, P. & Scherer, R.J. 2003. Generalised Model Subset Definition Schema, In: Proc. of the CIB-W78 Conference 2003—Information Technology for Construction, Auckland, NZ. Weise, M., Katranuschkov, P. & Scherer, R.J. 2004. Generic Services for the Support of Evolving Building Model Data, In: Proc. of the ICCCBE-X Conference, Weimar, Germany. Wix, J. & Liebich, T. 2001. Industry Foundation Classes IFC 2x, © International Alliance for Interopembility, http://www.iai-ev.de/spezifikation/IFC2x/index.htm.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

A software generation process for usercentered dynamic building system models G.Zimmermann & A.Metzger University of Kaiserslautern, Kaiserslautern, Germany ABSTRACT: The architects’ view of buildings is drastically changing because of technical progress, especially in control and facility management. Also, the usage of many buildings is often altered during their life time. Therefore, buildings have to be designed and maintained as systems including the users and uses over time. We have developed a formal building model that integrates the domains of building structures, service systems, control systems, functional units, and user activities. To intuitively model the dynamic behavior of user activities, we introduce a graphical modeling notation that we call Message/Transition Charts and show how these diagrams can semi-automatically be transformed into executable code. We believe that these contributions to the modeling of building systems and to transforming the models into simulators prove that architects, building users, and facility managers can efficiently be supported during the full life-cycle of buildings.

1 INTRODUCTION In architectural design four major stages are distinguished: the programming, proposal, main proposal, and the detailed design stage. During the lifetime of buildings, facility management stages and redesign or remodeling stages alternate. We foresee that in all stages there will be an increasing demand for models, simulations, and tools that incorporate user requirements and activities much more explicitly than it is the current practice. One of the reasons is that buildings are becoming technically much more sophisticated because of the embedding of digital control and communication systems as well as other technical advances. Such systems make the requirements analysis, design, use, and maintenance of buildings much more complicated for all stakeholders and add a new dimension of complexity. Another reason is a growing awareness that the building users should be in the center of attention during all stages and that a building should adapt to changing requirements of users instead of the other way around. In most building development, construction, and maintenance processes it is claimed that everything is done for the best of the user. It is assumed that the average user requirements are known and buildings that are built for these average users will fiilfill the requirements of the majority of users.

A software generation process for user-centered

327

However, post-occupancy evaluations show that this assumption is not true. There is no average user and all individuals have different requirements. Satisfaction case studies show—especially in the case of automated service systems with no user intervention— that in many cases the majority of the users is not satisfied and would like to get more individual control. Since satisfaction with the working environment is strongly correlated to productivity, much can be gained by improving satisfaction. Also, users often do not react to situations as assumed. This means that we are dealing with ranges of user requirements and non-deterministic behavior of individuals. Post-occupancy evaluations of users in buildings come too late in the process. Therefore, we propose the use of simulators to be able to experiment with groups of individual users, which also can have extreme requirements and exhibit non-deterministic reactions. We are aware that the dynamic behavior of persons is not well known and models of it are also based on average assumptions. Our hope is that by comparing simulations with observations of real users, the models can be refined over time. Advances in software and hardware technology and in computer science as well as software engineering provide us with the means to establish models, simulators and tools to support all stakeholders in coping with the problems that were mentioned above. One such approach for systematically coping with the complexity that is introduced by regarding sophisticated building technology and individual user activities is introduced in this paper. Still, it has to be clarified which questions computer simulation can answer that could not be answered by experienced architects or by stochastic models or calculations. At this time we can only make assumptions on the necessity of simulation. Applications of such simulators can show that these can provide solutions to the posed problems. One field we see as very difficult to tackle without simulation is the dynamic interaction of users with building control systems and the test and optimization of appropriate user interaction strategies. Simulations with user activities in a building system that is equipped with a control system could answer the question how little should be automated, how much user influence should be provided, how such systems should react to unexpected user behavior and how different control strategies influence the total building performance. The outcome might be that no control, computer aided control or the fully automated control should be preferred to provide optimal user satisfaction (and thus productivity) with little or no loss in energy efficiency. Other questions are related to the use of resources shared by many individuals of groups of users. Such resources are access and circulation areas and common facilities and equipment. Instead of using stochastic models, dynamic simulations with many individuals and situations could also provide answers about the average satisfaction or the satisfaction in extreme or unexpected situations. At this point, it should be stated clearly that we regard user activities as dynamic activities that happen over time. This means that the models and the simulators have to reflect this dynamics of user behavior in relation to time.

eWork and eBusisness in architecture, engineering and construction

328

2 RELATED WORK There have been discussions about the necessity of more formally taking user activities into account during the design and maintenance of buildings, and some progress has been made to achieve this goal. For example, Eastmann & Siabiris (1995) and Eck-holm & Fridquist (2000) have extended object structure models for building spaces by including organizations, user activities, and activity spaces. The purpose of these models is the formalization, communication, and storage of data, not so much the simulation. Eckholm (2001) introduced semi-dynamic user behavior by showing situations of user activities in a CAD-program. Dijkstra & Timmermans (2002) extended this notion into the dynamic domain by introducing models of space-time behavior of persons. They used agent technology to implement such models. Experiments have been conducted in the domain of pedestrians. The results are of great value in urban planning and also for the design and evaluation of transportation in general and of circulation areas in buildings. There is ongoing research to extend this work to other user activities in business processes. We have developed structural models of buildings as complete systems (Zimmermann 2003) that include users, user activities and activity spaces. These models provide the foundation for the automatic creation of simulators and is explained in Sect. 3. This paper demonstrates how this model can be extended to also include the dynamics of user activities. We have shown that physical effects that are observed in buildings (like heat or air flow) can be simulated by mapping simple physical objects into autonomous computational objects that compute the required physical results at run-time (Zimmermann 2002). We can use this technology to treat all physical simulation problems by integrating suitable computational objects into the building system model. The communication links between these objects can directly be derived from the static building structure in case of the domains regarded so far. Where the topology of the physical objects directly reflects the communication relationships in such a case (e.g., connected walls will exchange heat), this is not true when regarding users and their activities. The reason for that is that the topological relations change while users move (e.g., when going from an office to a meeting room) or change their memberships with certain groups (e.g., when changing the role from private person to employee). Additionally, the flow of messages and the behavior of the objects strongly depends on their state. For example, an occupied meeting room will force a user seeking for an area to hold a presentation in to search for a vacant room. Therefore, we need to augment the building models with that additional information. Unfortunately, all notations that are commonly available to the software engineer do not seem to be suitable for these purposes. A vast number of modeling notations, the so called scenario notations (Amyot et al. 2003), focus solely on the external communication between objects. Examples for such scenario notations are Message Sequence Charts (MSCs, cf. Braek et al. (1993)), UML Sequence Diagrams (Rumbaugh et al. 1999), or Use Case Maps (Buhr 1998). The behavior described in these scenarios usually only represents a single “run” of the

A software generation process for user-centered

329

modeled system, thus forcing the modeler to create lots of diagrams to achieve an overall understanding of the system. The concepts for hierarchical decomposition or repetition of partial scenarios as suggested in some of the notations (e.g., Hierarchical MSCs) only provides little help in our context. As an other extreme, there are modeling techniques that only allow for the description of the internal, stateoriented view of objects. SDUs state flow diagrams (Braek et al. 1993) or UML’s State Charts (Rumbaugh et al. 1999) are examples for such notations that are commonly accepted in industry and academia. Only UML Activity Diagrams (Rumbaugh et al. 1999) and variants thereof seem to support the mixed specification of (external) messages and (internal) states. However, the visual appearance and understandability by non-experts is far from ideal when the number of states to be regarded is increasing. It is the deficits of the above notations that made us conceive a new modeling notation, which we call Message/Transition Charts or MTCs for short (cf. Sect. 4). This paper will illustrate the notation’s elegance for the purpose of modeling user activities and dynamic behavior between distributed objects. 3 THE BUILDING SYSTEM MODEL Our approach bases on sound software engineering techniques that are applied to solve the problem of modeling building systems including user activities and to implement appropriate dynamic simulation environments in reasonable time. The most important techniques that are applied are structuring (or “separation of concerns”), iterative refinement, reuse, and model as well as code generation. Structuring is exploited throughout several dimensions. As a main structuring concept we have partitioned the building system model according to the domains: building structure, service systems, control systems, functional units, and user activities. All elements that are described by the sub-models of these five domains are further classified as being of type space or of type matter. As an example, in the building structure domain, the volume of a wall is considered as being of type space, where the materials that make up the wall (like bricks) are regarded as matter. Figure 1 shows the top level view of our building system model. All elements in this model are derived from the generic SystemObjectType. The Matter and SpaceTypes are found as specializations of this generic element (the more general element is depicted by the hollow arrowhead), as are the elements of the respective domains (e.g., BldSpaceT=BuildingSpaceType). All SystemObjectTypes are related by Requirements. Requirements are typically of such a form that an element in one domain requires a service that is fulfilled by one ore more elements in other domains. A basic structuring principle is that these requirements should only relate elements of the SpaceType if possible. In this way the spaces in the five domains together with the requirements, form the “backbone” of the overall building system model.

eWork and eBusisness in architecture, engineering and construction

330

Figure 1. Building system model (system level). Additional relations are depicted by the realizedBy arcs in Fig. 1, which bind together the matter and space elements of the respective domain. In many cases, the matter is of secondary importance and can be neglected in the early stages of modeling. Besides the connection of space elements through requirements, spaces can also be related to each other by topologic or geometric relationships. This is expressed by the spatial relation between the SpaceType in Fig. 1. If we begin to refine the models of the individual domains, the introduction of aggregation or composition relations (one element is made up of other elements) or other relations between space or between matter elements can become important. When refining the top level building system model to create the individual domain models, we use an approach of iteratively (step-by-step) refining these models following certain levels of detail. Figure 2 shows these five levels. The system level corresponds to

A software generation process for user-centered

331

the model in Fig. 1. From this level, the elements of the domain level are described first and then these elements are refined to form the application domain level. The different application domain models extend the level of detail of the domain models for different application domains. The elements of all models presented so far represent a classification of types of reallife objects (e.g., the office building domain model contains an OfficeType element, which is a type of a SmallOffice of an exemplary real-life object Office-32–419). Therefore, these elements form a library of so called metaobject-types that can be reused when creating new models. When these meta-object-types are instantiated they form the models at the project level, which consequently contains object-types (like the SmallOffice). Rather than linking the project and the application domain level with the generalization arrow, we use a simple line to depict this instantiation relationship. When the project level models are transformed into simulators (see Sect. 5) and executed, the runtime-objects (that are instances of the object-types) reflect the real-life objects at the run-time level of the model hierarchy.

Figure 2. Model hierarchy.

eWork and eBusisness in architecture, engineering and construction

332

Figure 3 shows the user activity domain model as a more detailed example of a model at the domain level. The generalization relations to elements of the building system model are depicted by angle brackets. The types of roles that can be taken on by individuals (IndivRolT) are composed of different individual types of activities (IndivActT), which themselves can consist of more fine-grained activities. Accordingly, group role types are defined. Refinements of this model (at the application domain level) are meaningful in different domains like office buildings, factories, or homes. For the offlce building domain model (see Fig. 2) we would derive elements such as ManagerType, SecretaryType, and VisitorType from the element IndividualType. In home applications, other refinements would apply. The reason for this seemingly complex structure of levels and domains is as follows: We do not aim at creating a monolithic simulation environment for building systems that integrates all possible alternatives of such systems as well as their usages and that can only be personalized by setting a large number of parameters. We rather aim at a systematic and efficient method for constructing customized simulation environments for each application of such simulators. The above structuring and reuse concepts provide the framework for such an approach to be successful.

Figure 3. User activity domain model.

A software generation process for user-centered

333

4 MESSAGE/TRANSITION CHARTS After having modeled the structure within the five domains with sufficient detail, we have to define the behavior of the respective objects. As it has been noted, we concentrate on user activities in this paper, which especially includes the specification of roles and activities that make up these roles (see Fig. 3). It is obvious that different users and roles are active concurrently. Therefore, a well fitting computational model for describing this behavior is a set of communicating, concurrent objects. A first step in specifying models of such concurrent objects is a rather abstract and well-structured description, which depicts the communication between objects and their change of states (state transitions) as triggered by the reception of messages. From these high-level models, more detailed models can then be created that represent the input to the simulator generation process as described in Sect. 5. As it has been motivated in Sect. 2, we will use our notation of Message/Tmnsition Charts (MTCs) as a suitable diagramming technique for such an abstract description. MTCs consist of a few basic building blocks that can be structured in a hierarchical fashion. At the lowest level, states of objects are identified (like the states occupied and vacant that we have introduced in Sect. 2). These are depicted by small rounded rectangles. Messages (painted as thick arrows) can trigger a change of states, i.e. a state transition (depicted by thin arrows), which can imply the creation of new messages that are sent to other objects.

Figure 4. Example of a Message/Transition Chart. Object boundaries are drawn as large rounded rectangles. As we are modeling user activities with objects, such boundaries can show the boundaries of activities as well. Figure 4 presents an example with two such activities, each having two states and two transitions. This figure also shows the more advanced modeling constructs that are available in the MTC notation. Small circles depict connection points that allow the usage of parts of the

eWork and eBusisness in architecture, engineering and construction

334

diagrams in a hierarchical fashion (the usefiilness of this feature will become obvious in Sect. 6) or the connection of message flows (as shown within act2). When the transition from state S1 to S2 is taken, a new message m3 is created. The text included in parentheses following the message name specifies optional parameters of this message. In the above figure the message m3 has the parameter a. Depending on the value of a, one of the two transitions in act2 is triggered. In the case that a is one, the message m4 is created. An MTC thus presents a set of possible chains of messages in one single and easily comprehensible diagram, which neatly reflects the behavior we want to model on an abstract level. The editing of MTC diagrams as well as the hierarchical management of parts of such diagrams is supported by a tool that we automatically created from a formal tool specification using the Meta-CASE environment DOME (Engstrom et al. 2000). 5 SOFTWARE GENERATION PROCESS As it has been motivated above, our goal is the systematic an thus efficient construction of customized simulation environments. One potent way of gaining efficiency is the automation of repetitive or complicated tasks that can be described by simple strategies (or algorithms). One such task is the transformation of parts of the building system model into executable code. Like a programming language compiler automatically creates an executable application from its source code, we will show that the same powerfiil technique can be employed for generating building simulators from our building system models.

Figure 5. Simulator creation process.

A software generation process for user-centered

335

The overall process for attaining simulators is depicted in Fig. 5. The start of the creation process is the structural model of the building system, which is augmented by the behavioral description through MTCs. An example for such models will be shown in Sect. 6. From the augmented building system model, tabular documents are created by the simulator developers. These documents, which are part of our software development method PROBAnD (Metzger et al. 2002), contain the formal specification of the structure, the behavior (specified by state transitions) as well as the messages that are exchanged. Many tasks during the mapping of the MTC models to these PROBAnD documents are straightforward and could be automated easily. However, as we first wanted to gain experience in applying the MTC notation we have so far refrained from implementing such automation tools. As Fig. 5 shows, the PROBAnD models are then used to automatically generate models in the specification and design language SDL (Braek et al. 1993). We have shown the feasibility and the technicalities of this approach in (Metzger et al. 2003) and refer the interested reader to this publication. Usually, the generated SDL models are complete and can directly be used for generating executable simulators (Zimmermann 2001, 2002). If not, extensions or modifications can be performed by the developers. We have used the commercial code generator Telelogic Tau for automatically generating simulators from such SDL models (Mahdavi et al. 2002). SDL has been the language of our choice because it allows for the specification of independent objects (called processes) and the description of the object behavior by (extended) state transition diagrams, thus presenting a seamless progress from the stateoriented descriptions in the MTCs. Further, interactions between processes are modeled as message exchanges. 6 UNIVERSITY BUILDING EXAMPLE The above generation process has been successfully applied to the building and control domain, where we can rely on thorough experience for behavior specification without the need of using MTC models as an intermediate step. As we have pointed out numerous times, such a behavior specification is more complex for the user activity domain. Here, we will demonstrate—by using a small and simple example—how MTCs can be used for that. Let us assume that we want to model the user activities within our university complex (called UKL) as an instantiation of the application domain model for specifying office buildings. Our UKL secretaries, which are of the type SecretaryT, take the role of a UKLSecretary upon entering her office and starts with the activity desk work that might consider the special context of working at our university. During the work hours the person in this role might interrupt the desk work to make copies, meet with the manager, etc. In all cases the person has to move from one place to another. Already this very simplified example creates many requirements that have to be fulfilled by objects of other domains. For example the role of a secretary occupies an

eWork and eBusisness in architecture, engineering and construction

336

qffice place, desk work requires a desk place, move uses circulation space, and so on. These places require building spaces and services. Typical services are sufficient light levels, which can be provided by natural or artificial sources under automatic or manual control. Some of the requirements are more static in their nature; e.g., building space requirements. But the fulfilment by actual spaces can change when a desk is moved, causing a chain reaction in the resulting requirements. Other requirements like circulation space requirements are of a dynamic nature in relation to an individual. Also, such spaces can be shared, but limited resources. This example shows the occurrence of many requirement chains that are interrelated and can form complex graphs. To be able to model the fulfillment of all requirements and simulate a possible solution, we have to model the structural relations of all involved objects and the behavior of the resulting system.

Figure 6. Excerpt of the UKL user activity project model. The structure is modeled at the project level by object-types that are instantiations of the meta-objecttypes from the application domain level; e.g., the UKLSecretary is of the type SecretaryT (see Sect. 3). As a modeling notation we use UML Class Diagrams (Rumbaugh et al. 1998). These diagrams have already been used for the introduction of the building system models. Figure 6 shows a small portion of the structural parts of the UKL user activity project model as a further example. In contrast to the example of Fig. 3, this figure uses the colon “:” to depict the fact that the element to the left of the colon has been created by

A software generation process for user-centered

337

instantiating the element to the right of the colon; e.g., the object-type UKLSecretary is an instance of the SecretaryType of the application domain model. Each UKLSecretaryRole aggregates one instance of the individual activities of UKLDeskWork, UKLMakeCopy, UKLMove and UKLMeet, which have to be active in mutual exclusion. The most abstract view of this behavior of the UKL secretary role can be specified with the MTC as it is shown in Fig. 7. In this diagram we have reduced the number of arcs by using bidirectional arrows for the messages if applicable (the “>” and “<” symbols show the direction of the labels). Also, for brevity, parameters have been omitted. At the top of the diagram, the hierarchical activity UKLSecretaryRoleCtrl represents an object that controls the overall behavior of the UKLSecretaryRole (the folded corner is a visual cue that a refinement of this activity exists). All other nodes within UKLSecretaryRole represent instances of activity types, whose behavior is defined elsewhere. It should be noted that the instance mov1 only exists once and is shown in three shared copies to simplify the layout. Outside of UKLSecretaryRole the person UKLSecretary, is shown, which takes on the role of “secretary” upon arriving at work. A first activity within this role is the secretary’s move to her desk to begin the desk work. This desk work can be interrupted (triggered by the actionCtrl message) and either a meeting or a copy job can be performed. In each case, the secretary has to move to the respective places.

Figure 7. Message/Transition Chart for UKL secretary role.

eWork and eBusisness in architecture, engineering and construction

338

This diagram also shows the interface to objects within the ftinctional unit domain (connection points on the right hand side of Fig. 7). As an example, the desk work activity needs to get a desk or the copy activity needs to enter the copy place. Because of its abstract nature, the MTC in Fig. 7 allows for different alternatives of the dynamic behavior and the control of the different activities. The simulation environment could very strictly control all activities by sending simulatorCtrl messages with exact timing and ftmctionality requests. Typically, parameters of messages from outside of the simulated domains would be provided by files. Therefore, the results of such experiments would present a repeatable outcome. In contrast to that, simulation control could be very loose by giving the objects autonomous control, similar to the concept of independent agents. A non-repeatable behavior would result, which could be analyzed with statistical methods. Finally, an indeterministic behavior could be achieved by using random generators that influence the objects’ behavior. In such a case, the simulation environment could be used to control the stochastic parameters. We believe that this large range of behavioral alternatives can be employed to easily realize a variety of different experiments. There are different options for the further use of this abstract MTC: First of all it can be employed to define all external and internal message interfaces of UKLSecretaryRole for the subsequent stages of the software generation process. Second, it can be extended by modeling the other domains at the same level of detail (connecting the MTC with MTCs of the other domains). Third, it can be refined by completing all message relations and by precisely modeling UKLSecretaryRoleCtrl in detail. Figure 8 shows one such possible refinement.

A software generation process for user-centered

339

Figure 8. Refinement of UKLSecretaryRoleControl. Before the role has been taken on by the secretary, it is in the state undeflned. As soon as the response message (from the desk work activity in Fig. 7) arrives, the state of the role changes. If the secretary has just taken on the role, she starts working. If she has just been away for a meeting or a copy job, she resumes her work. Upon the first transition from undefined to working, the occupOffPlace message is sent to the respective object in the functional unit domain such that the occupancy of the person is noted (the message parameter is true). Whenever the simulation control environment triggers a new action, the request for this action is propagated to the desk work activity. If the simulatorCtrl message requests quitting the role (because the working time might have ended), the state of the role

eWork and eBusisness in architecture, engineering and construction

340

changes to undefined and the functional unit is notified that the office place is no longer occupied by the secretary. The hierarchical decomposition that we have illustrated above can be used at as many levels as seem to be suitable, and therefore allows us to handle very complex systems. At the bottom of this composition hierarchy, simple objects (or activities) reside that are solely specified by states and state transitions with the appropriate actions (the UKLSecretaryRoleCtrl has been an example for that). The “secretary” MTC can easily be reused for creating models for other roles like a “manager” role. Such a role could make use of the same or other elements as needed. To support such kinds of reuse, we maintain an MTC library, which is extended with every new project. Besides these abstract behavior descriptions, the library also contains the refinements of these descriptions in the form of PROBAnD models to speed up the simulator generation process. 7 CONCLUSION AND PERSPECTIVES This paper has shown the feasibility of efficiently creating customized building simulators for various application domains. The examples that were presented as a motivation for creating such simulators might seem obvious. Nevertheless, we hope that once architects realize the potential of such a custom-specific tool generation, they will come up with more interesting concepts for performing experiments and evaluations of buildings before these are erected. We believe that this area of building simulation is a very promising field for both building and software architects to work together productively. Our vision is that architects will be able to create the abstract behavioral and structural models (i.e., the project level models) from which the software architects (software engineers) can take over and refine these models into running simulators. We hope that the small examples of our Message/Transition Chart notation has supported the visual appeal and ease of understanding of modeling at this level and will provide a basis for further discussion in the field of modeling user activities and processes. REFERENCES Amyot, D. & Eberlein, A. 2003. An Evaluation of Scenario Notations and Construction Approaches for Telecommunication Systems Development. Telecommunication Systems. 24(1), (2003): 61–94. Braek, R. & Haugen, O. 1993. Engineering Real-Time Systems. An Object-oriented Methodology Using SDL. New York, London: Prentice-Hall. Buhr, R.J.A. 1998. Use Case Maps as Architectural Entities for Complex Systems. IEEE Transactions on Software Engineering. Special Issue on Scenario Management. 24(12), (1998): 1131–1155. Dijkstra, J. & Timmermans, H. 2002. Towards a multi-agent model for visualizing simulated user behavior to support the assesment of design performance. Automation in Construction. 11(2002): 135–145.

A software generation process for user-centered

341

Eastman, C.M. & Siabiris, A. 1995. A generic building model incorporating building type information. Automation in Construction. 3(1995): 283–304. Eckholm, A. & Fridquist, S. 2000. A concept of space for building classification, product modelling, and design. Automation in Construction. 9(2000): 315–328. Eckholm, A. 2001. Activity Objects in CAD-programs for building design. Computer Aided Design Futures, Einhoven, Einhoven,Netherlands, 2001. Engstrom, E. & Krueger, J. 2000. Building and Rapidly Evolving Domain-Specific Tools with DOME. IEEE International Symposium on Computer-Aided Control Systems Design. Anchorage, Alaska. (2000): 65–70. Metzger, A. & Queins, S. 2002. Specifying Building Automation Systems with PROBAnD, a Method Based on Prototyping, Reuse, and Object-orientation. OMER—Object-Oriented Modeling of Embedded Real-Time Systems. GI-Edition, Lecture Notes in Informatics (LNI), P5. Bonn: Kollen Verlag (2002): 135–140. Mahdavi, A., Metzger, A. & Zimmermann, G. 2002. Towards a Virtual Laboratory for Building Performance and Control. Cybernetics and Systems 2002. Vol. 1. Vienna: Austrian Society for Cybernetic Studies. (2002): 281–286. Metzger, A. & Queins, S. (2003) Model-Based Generation of SDL Specifications for the Early Prototyping of Reactive Systems. Telecommunications and beyond: The Broader Applicability of SDL andMSC. Springer Lecture Notes in Computer Science, LNCS 2599. Heidelberg: Springer-Verlag. (2003): 158–169. Rumbaugh, J., Jacobson, I. & Booch, G.. 1999. The Unifled Modeling Language Reference Manual. Reading, Harlow, Menlo Park: Addison-Wesley. Zimmermann, G. 2001. A new approach to building simulation based on communicating objects. Seventh International IBPSA Conference Proceedings. Vol. 2. Rio de Janeiro, Brazil (2001): 707–714. Zimmermann, G. 2002. Efficient creation of building performance simulators using automatic code generation. EnergyandBuildings. 34. (2002): 973–983. Zimmermann, G. 2003. Modeling the building as a system. Eighth International IBPSA Conference Proceedings. Einhoven, Netherlands. (2003): 1483–1490.

Process modelling technology

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Embedded commissioning for building design Ö.Akin, M.T. Turkaslan-Bulbul & I.Gursel School of Architecture Carnegie Mellon University, Pittsburgh, USA J.H.Garrett Jr, B.Akinci & H.Wang Department of Civil and Environmental Engineering, Carnegie Mellon University, Pittsburgh, USA ABSTRACT: Building commissioning has a broad scope that extends to all phases of building delivery. We view commissioning as a building delivery embedded process that persistently verifies and validates design intent throughout the building lifecycle process. In the building lifecycle approach, buildings are considered to have cradle-to-grave life spans. They are modeled through a variety of different developmental phases. In this research project, we intend to build the necessary theory and tools to support the embedded commissioning process as a co-function of building lifecycle.

1 INTRODUCTION Building commissioning is an important new area of practice and research in the industry. It has emerged, during the last 25 years, as the central phase of building delivery that is responsible for verifying design intent. Currently, it is rapidly becoming the performance verification tool in HVAC design and LEED (Leadership in Energy and Environmental Design) certification in the USA. Building commissioning is a multi-phase process that ensures the interacting systems in a building are properly installed and operating. In the early phases of facility design, commissioning is concerned with whether the program and the design are delivering the owner’s desired functionality. During the construction process, commissioning is concerned with ensuring that the performance of the selected building equipment agrees with the design specifications and delivers the intended fimctionality. The process of building commissioning tends to generate large amounts of data, much of which needs to be shared across other facility delivery phases. We view commissioning as a building delivery embedded process that persistently verifies and validates design intent throughout the building lifecycle. The Embedded Commissioning Model (ECM), which is described in this paper, combines the processes of commissioning and building life-cycle in order to provide a framework for managing the information exchange between them. Here, the role of commissioning is to complement each of the lifecycle phases and their interactions through timely building system evaluation. The primary objective of our study is to investigate the computability of Embedded Commissioning (EC) for HVAC systems. Our approach focuses on exploring the

eWork and eBusisness in architecture, engineering and construction

344

representational needs of the EC process and the management of EC data. Here, we concentrate on how the EC process works? What kind of information is produced; and what type of attributes can be defined? The output of this study is used to develop a proof of concept prototype software that supports the decision making process in EC. 2 RESEARCH BACKGROUND 2.1 History The term commissioning has originated from the naval practices. Commissioning ceremony is a sign that the ship is accepted as an operating unit of the navy. By breaking the commissioning pennant the ship is put into the responsibility of the commanding officer who together with the ship’s crew has the task of making and keeping her ready for any service required during peace or war. Prior to commissioning, the newlylaunched vessel must pass some tests before she is considered complete and ready to be authorized as a commissioned ship. The new ship goes through several sea trials during which deficiencies that need correction are uncovered. The crew and the ship must function in total harmony for maximum effectiveness and efficiency (Reilly 1975). The association between ships and buildings is not new but commissioning was introduced into the building industry only during 1977. Public Works Canada is the first organization who started to use commissioning in project delivery. Then in 1981 Disney Inc. issued a comprehensive commissioning program in the design, construction and start-up of its Epcot theme park. In the United States of America, formal work on the commissioning process began in 1984 when the American Society of Heating Refrigerating and AirConditioning Engineers (ASHRAE) formed Commissioning Guideline Committee. The task of the committee was to define a process which guarantees that fully fimctioning buildings were turned over to the building owners. The motivation for the ASHRAE Commissioning Committee was the growing number of complaints about unmanageable HVAC systems, increasing operation expenses, decreasing comfort levels, and uneducated operations and maintenance staff who did not understand how to maintain or operate new buildings. After its foundation, the ASHRAE commissioning committee published two guidelines. The original guideline was announced in 1989 and an updated version has been published in 1996 (Guideline 1996–1). After the announcement of ASHRAE Commissioning Guidelines, commissioning practice started to draw attention from various areas. University of Wisconsin, Madison offered commissioning courses and University of Michigan established a facilities evaluation and commissioning group. In 1993 first National Conference on Building Commissioning (NCBC) was held and National Environmental Balancing Bureau (NEBB) developed a commissioning providers’ certification program. After 1993 a range of governmental and private organizations started commissioning practices and issued regulations or guidelines. In 1998 US Green Building Council added commissioning to Leadership in Energy and Environmental Design (LEED) criteria. Finally, in 1999 the Building Commissioning Association (BCA) was established.

Embedded commissioning for building design

345

2.2 Deflnition ASHRAE defines commissioning as the process of ensuring that systems are designed, installed, functionally tested and capable of being operated and maintained to perform in conformity with the design intent (Guideline 1–1996). Commissioning is a systematic approach. It starts with the programming phase and ends when the building is turned over to the owner. Most commissioning companies also provide a one or two year guarantee phase after the building is occupied. During the commissioning period the aim is to ensure and verify, with documentation, that all building systems perform in the way that they were intended and the operating and maintenance staff is trained according to the owner’s operational needs. Commissioning is occasionally confused with the testing, adjusting and balancing (TAB) process or the punch list inspection process. The latter is a physical examination done before a building is turned over to its owner. It is a one day process at the end of which a list of missing elements are identified such as “door stops are missing” or “vinyl base needed in the emergency exit stairway.” TAB is a more complex process than punch list inspections. It measures air and water flows in building’s HVAC systems. Punch list inspections and TAB process mainly focus on items that are important to get regulatory occupancy permits and opening the building. Commissioning covers a much broader scope of work than these inspections. It necessitates functional testing to determine how well building systems perform together and verifies the results of TAB reports. Applying fimctional tests to individual equipment and whole building systems also help determine whether the tested item meets operational goals or if it needs modification to increase its efficiency and effectiveness. This standard definition of commissioning refers to a process which starts at the building’s design phase and ends when the building is turned over to the owner. However existing practice of building construction does not require building owners to hire a commissioning professional at the beginning of the project. The commissioning processes can be adapted to any phase during the lifecycle of a building. 3 PROBLEM STATEMENT The conventional building delivery process begins with the recognition of the need for physical intervention and concludes by the eventual decommissioning of a building having gone through a set of predefined stages (Davis et al. 1974). We use the term “building lifecycle” as a reference to an expanded and improved version of such conventional delivery models. In the building lifecycle approach, buildings are considered to have cradle-to-grave life spans. They are modeled through a variety of different developmental phases, rather than a set, lockstep procedure. These phases include: requirement specification, design specification, facility construction, facility (de)commissioning, facility (re-)occupancy, facility management, and materials recycling. They can take place, iteratively, in smaller or larger process cycles, at anytime during a building project’s lifetime.

eWork and eBusisness in architecture, engineering and construction

346

Figure 1. Embedded Commissioning Model: integrating the Commissioning Process with the Building Lifecycle Process. The role of Embedded Commissioning (EC) in this cycle is to accompany each of these phases and their interactions with timely building system evaluation. Figure 1 shows the function of Embedded Commissioning Model (ECM), which mediates between commissioning and building life-cycle for managing the information exchange between them. For instance, facility construction normally would begin once design specification is complete. Commissioning, at this point, would serve as the evaluation aspect of the construction process, periodically verifying the accuracy of what is being constructed against available specifications, whether these are of a design or requirement type. In response to this evaluation, the construction process would either continue as planned or be modified. This kind of feedback cycle is imaginable for all eight phases of the lifecycle model shown in Figure 1. Furthermore, by considering commissioning as a parallel and interconnected activity we intend to realize its potential impact for the entire ECM for all phases of the building lifecycle. In order to consider the implications of this approach we will analyze the role of EC in the “design specification” phase, just one of the eight shown in Figure 1, as a descriptive example. 3.1 Descriptive example: design specification phase of embedded commissioning model There are three major factors that inform the potential impact of commissioning on design specification: decision complexity, system integration and information seams of the lifecycle model.

Embedded commissioning for building design

347

3.1.1 Decision complexity In the design specification phase, particularly in the earlier stages, one of the most difficult challenges is to manage complexity. This complexity arises from the inherent interdependence between different design decisions (Akin 1978). For instance, determining the number of floors in a hospital building, the distribution of the hospital functions on each floor, the organization of circulation into various configurations, can constitute important design decisions. Deciding to create a tall hospital building will impose important constraints on the circulation diagram on each floor. Depending on whether correlated programmatic functions can be located on the same floor, an appropriate circulation concept—say, a linear, concentric, or satellite type—may be used. This in turn can determine the overall building configuration. In a real design situation there would be many more factors to consider, such as, cost, zoning limitations on building height, mechanical systems and their zoning requirements, and visual appearance. Potentially, all of these factors may influence how such a building’s spatial configuration decisions are made. Many of the consequences of such decisions would become apparent only when downstream decisions are made. Consequently, in order to manage the complexity factor, many iterations would be required to synchronize upstream decisions with down stream ones. 3.1.2 System integration Another aspect of the interaction of design and commissioning in the ECM is the unpredictable results of synergy that potentially exists between separately designed building subsystems. Structural systems can interfere with mechanical distribution. Lighting systems may cause extra cooling loads for the HVAC system. Circulation configurations may reveal unexpected privacy needs of occupants. Sometimes the only way to discover, let alone, resolve such conflicts, is to conduct elaborate simulations of proposed designs. It may even be plausible to accomplish this during the construction commissioning phase, that is, if the design allows for evolutionary construction stages planned to respond to the findings of persistent commissioning activities, as would be the case in ECM. This suggests a design process which relies on persistent refinement and evolution of the design through evaluation and commissioning. While it would be impossible to do this with all aspects of a design problem, there are some subsystem performance values that are so difficult to predict during the early design process that it would even be desirable to postpone detailed decisions until after either design simulation or construction commissioning takes place. For example, some of these performance categories include: HVAC systems, acoustic systems, operable-window use patterns, vertical circulation use patterns, and emergency egress behavior. 3.1.3 Information seams in building delivery In the traditional building delivery process, some of these hot points of design refinement are managed through conventions of the design-delivery practice.

eWork and eBusisness in architecture, engineering and construction

348

For instance, architects and their consulting engineers occasionally specify building designs only partially. They, intentionally, rely on the general contractors and their subs to provide the fabrication details for individual structural components or mechanical equipment. These are called shop drawings. Furniture manufacturers and cabinet makers, often wait to obtain as-built drawings and dimensions before they design and fabricate furaishings. Similarly acoustic engineers rely on measurements and readings taken at the site. They also use mockups before finalizing their designs. It is not uncommon that paints and other finishes, even major cladding elements like brick and stone, are evaluated through samples installed at the site before final approvals are given. Even when such sampling and measurements are made, it is not unusual to end up with insufficient data about existing conditions. Soil samples, for example, may not tell the entire story about what can be uncovered at the site once excavation takes place. At the time of demolition, existing structures on a site usually reveal more than just a few surprises. The potential impact of some of these problems fit nicely into the professional knowhow of specific building trades or the practices that apply to the individual stages of the delivery process. But others fall squarely at the boundaries of these stages or professional domains. This is precisely the reason why explicit protocols for information exchange between trades do exist. For example, it would be counter productive for the designers to prepare shop drawings for the steel work. Only the steel contractors would know with certainty how to meet the design requirements in the most economical and practical manner. One of the formal procedures for bridging such a seam is, in fact, the shop drawing preparation and approval process. In practice, these procedures are imperfect. Many failures in buildings, some of which have achieved national notoriety, have been linked to information loss that has occurred at the shop drawing preparation and approval stage of building delivery—John Hancock Tower, Boston MA; Citicorp Tower, NY, NY; Kansas City Hyatt Regency, Kansas MO (Akin 2001). 3.2 Implications for the embedded commissioning approach The Embedded Commissioning Model (ECM), integrating commissioning within building lifecycle phases, is intended to address the need for continuous evaluation during not only the design specification phase (as addressed above) but also for all of the other phases of building lifecycle. This model is proposed as a framework to address problems of information management, such as the ones described in the previous section—decision complexity, system integration and information seams. The primary mechanism in this model is to execute each phase with the expectation that persistent evaluation will provide guidance for downstream decisions, based on ongoing commissioning measurements and simulations. We expect that this will significantly improve performance during all of the stages of the building lifecycle. For example in design specification phase two important improvements can be affected: (1) scoping design intentions more accurately based on greater downstream information obtained through the embedded commissioning process; and (2) phasing the entire scope

Embedded commissioning for building design

349

of design intentions into smaller installments, in order to match them against the stages of ECM. What we have outlined here for the design specification phase, we expect, holds for the other phases of building lifecycle, as well. The scope of our overall research program then is to identify process flow of embedded commissioning in building lifecycle phases and develop a data model that represents the information in it. These are going to be a base to build a computer assisted decision tool to enable all of the information exchange links between building lifecycle phases and the embedded commissioning activities. In this paper, due to space limitations, we consider a much smaller portion of this agenda. In particular, we will describe a process model developed for commissioning HVAC systems during the facility programming, design, construction, acceptance and post-acceptance phases. We will then explain ECM data model that is developed to represent the information in our EC process model. At the end we will discuss a proof of concept application limited to the HVAC systems during the facility construction phase. 4 APPROACH Our approach to investigate the computability of Embedded Commissioning is built on the formal representation of its process and data models. 4.1 EC process model In almost every commissioning related source there is a description of how building commissioning should be done. Our aim for developing an EC flow chart was identifying a standardized process that we can use in our research. We used ASHRAE’s commissioning description in its Guideline 1–1996 as our starting point. We have conducted a detailed study of the commissioning process described in that guideline. This revealed a well-structured methodology and yet promises to lead to a guide for people involved in building delivery, so as to achieve efficient, effective, and high quality HVAC systems. The ASHRAE guideline provides a model that shows commissioning activities step by step. However this model does not present the details of the flow of EC processes and their connec- tions to different building delivery stages. In order to develop a comprehensive model we conducted a detailed observation of an HVAC commissioning process of a new university dormitory at Carnegie Mellon University, in Pittsburgh, PA. We interviewed the commissioning team in order to primarily learn about a specific case of commissioning in detail so as to gain insights about the mechanics of the process. Our aim in this observation was to explore the larger context of EC and how it works in the normal. We analyzed the dormitory case so as to illuminate commissioning as a normative process. We are particularly interested in understanding the precise protocols and documents used in their inspections, tests and measurements, and the role of these documents in different phases of commissioning. In our analysis of the ASHRAE guideline and dormitory commissioning, we described the EC process as an inclusive process flow illustrating every task, document and decision culled from all phases of commissioning (Akin et al. 2003). The flow chart is organized in the form of a design-bid-construct process which has five main phases:

eWork and eBusisness in architecture, engineering and construction

350

program phase, design phase, construction phase, acceptance phase and postacceptance phase. All HVAC commissioning procedures are explained in relation to these building stages. Figure 2 is an example from our flowchart that shows the programming and design phases. In our study, this detailed process model was important for three reasons. First, it showed us how people interact with each other during the commissioning process. Second, we could track how and what kind of documents are produced in this process and how they evolve throughout the flowchart Third, it helped us to recognize the type of data used in EC, which needs to be identified and modeled. 4.2 EC data model After completing the EC process model we started to model EC data. Data modeling for Embedded Commissioning has three steps. The first step is about identifying building commissioning data. In this phase, we looked at commissioning related information produced by different sources such as commissioning companies and organizations that publish commissioning guidelines or regulations. We compared these different groups of data through comparative analysis tables (CAT) and prepared a normalized data set. In the second step we defined the structure of the data model that represents our normalized data set consistent with the needs of the EC process we defined in our EC process model. The third step of modeling EC data involves testing the developed model with existing building product models. We tested IFC’s in order to determine their degree of support of the commissioning process and the possibility of data exchange in this context. 4.2.1 Identifying commissioning data While modeling the embedded commissioning process we have identified a group of commissioning data. In order to develop a normalized and consistent data set, we compared the data we have with other commissioning data produced by other sources. In our initial comparisons, we saw that commissioning data shows variations according to the source type. For accurate comparisons we identified four groups of commissioning sources: (i) data sheets of practicing commissioning agents; (ii) commissioning guidelines coming from organizations such as the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), National Institute of Standards andTesting (NIST); (iii) equipment specifications of HVAC manufacturers such as Trane and Carrier; and (iv) the products of other research groups. Data coming from different sources are compiled into Comparative Analysis Tables (CAT). The comparison analysis tables are laid out according to various pieces of HVAC equipment, and each corresponding attribute is listed across the table to identify possible matches or similarities in that specific component’s unique properties. By identifying prevalent attributes relevant to certain equipment, we were able to compile generalized properties of those components with the intention of using them to define the parameters of the models in our research. In CAT a column contains data coming from a specific source and same attributes are placed in same rows. For example in Table 1 “Fan Capacity”, “Air-flow (cfm)” and “Fan CFM (total/return/outside/discharge)”; coming from Source 1, Source 2, and Source 3

Embedded commissioning for building design

351

respectively; refer to the same attribute of HVAC equipment, fan. So they are all placed in the same row. However “Fan noise class” property from Source 1 does not have any match from Source 2 or Source 3. Respective cells left empty in those rows. We selected three types of HVAC equipment according to the complexity of their attribute types. These types of equipment are the air filter, fan and Air Handling Unit (AHU). An air filter is a simple, single piece of equipment. It does not have too many variations and has a constant set of attributes for all air filter types. In comparison to the air filter, the fan is a more complex piece of equipment. According to its functionality, there may be hundreds of different varieties and fan attributes which change with respect to these variations. An AHU is the most complex piece of equipment that we have modeled, since it consist of other pieces of equipment, such as coils, air filters, control sensors, supply and exhaust fans. Different combinations of these pieces of equipment can potentially create thousands of distinct AHU assemblies. Usually, the exact attributes of an AHU depends on the equipment types from which it is made. We developed CATs for all three equipment types. The table produced for air filter was simple and it showed us that this comparison method is suitable for our work. The challenge in preparing a CAT of fans was to group fan types into reasonable categories that can be represented in our data model. For AHU it was not possible to put all information into one table. Instead we identified components of a medium AHU and compiled CATS for all of them. We identified nine components: air filters, fans, coils, sensors, humidifiers, ducts, dampers, pumps, VAV boxes, economizers.

eWork and eBusisness in architecture, engineering and construction

352

Figure 2. Programming and Design phases from EC Process Model. Table 1. Structure of Comparative Analysis Tables (CAT).

Embedded commissioning for building design

353

The challenge in describing commissioning data, in this fashion is to limit the number of sources to seminal ones. Every new source may bring a new attribute that has not been captured in the previous sources. This may be due to the type of source, type of commissioning practice or the type of building that has been commissioned. Our aim in identifying the commissioning data is to collect a reasonable number of attributes that refer to a comprehensive commissioning process. When we reach this point, new data additions will remain marginal. For air filters and fans we collected an adequate amount data. 4.2.2 Structure of data model We have developed our EC data model simultaneously with EC data identification. This was advantageous for us since it allowed refining the data model as EC data were updated. EC data modeling starts with understanding how the EC process works. For this, we relied on the model that we created previously. Our building commissioning data model is based on the assumption that there are three events in the building commissioning process that

eWork and eBusisness in architecture, engineering and construction

354

Figure 3. EC Data Model Structure. define EC data. These events are specification, system context inspection and functional inspection. Speciflcation is done in the design phase and it describes the performance criteria. System context inspection and functional inspection are post-construction events and actual commissioning takes place through these inspections. System context inspection is a qualitative evaluation of the equipment and its content (e.g. “is the AHU properly supported”) whereas functional inspection takes actual measurements and compares them with the values defined in the speciflcation event. The data in these events are organized in a hierarchical order from more general to specific. Figure 3 explains structure of our model according to this three event organization. The root of the model is Event class from which Performance Description and Inspection classes inherit their properties. Performance Description class represents the speciflcation event and Inspection class represents the system context inspection and functional inspection events. They are specified as Functionallnspection and SystemContextInspection classes in the third level. Specific information for every piece of equipment is added as branches to this structure. Figure 4 shows a part from EC model that is developed in UML, accordingly. Our aim in developing this data model has been to represent EC data in the real world. From our process model we know that real world commissioning exists under volatile information conditions. However our current data model represents only a stable group of data and any condition of unpredictability is a challenge for our model. Currently, we are working on refining our model for these volatile conditions. In the future, we will update our EC data model in a way to represent both predefined and yet-to-be-defined data. 4.2.3 Testing how well IFC releases support EC model The adequacy of IFC data exchange standards are tested with the developed EC data model in order to determine the degree to which the IFCs support the

Embedded commissioning for building design

355

Figure 4. Partial EC Data Model. commissioning process and explore the possibilities for data exchange. Due to space limitations we will only report the results of our testing. Further information can be found in other publications (Garrett et al. 2004). IFC releases provide a capability to exchange any customized data by using the IfcPropertySet as a general container. However, IfcPropertySet only works within a single system because it does not have a public schema, which is the very protocol external applications expect during the data exchange. Among all current EC entities, relationships and attributes in the EC model, about 30 percent of those data items can be fully matched to the entities in the most recent release of the IFC data exchange standard, R2×2. For example, in IFC R2×2, Equipment entity, which stands for HVAC equipment, is represented by IfcElement and Event entity, which stands for commissioning activity, is expressed by IfcTask. IfcRelAssignToProcess entity is used to represent three kinds of relationships between Equipment and Event entities: functional_inspection, specification, and system_context_inspection. For the high level classes, e.g. Equipment, Event and their direct subclasses, more than 60% of attributes can be represented by standard IFC classes and IFC R2×2 even supports more than 90% attributes. That value even gets higher when we consider partially matched items. For the classes that are bound to special object or activity, e.g. CentrifugalFanContext and VaneAxialFanPerformance, the quantity of matched items is smaller. Even IFC R2×2, which has improved its HVAC domain greatly, can only fully match less than 20% BC attributes, in detail. 5 PROOF OF CONCEPT PROTOTYPE The state of the art in current software support for building commissioning has two trends. In the first trend, commissioning is seen as an extension to information monitoring or building performance diagnostics tools (Piette et al. 2001, Castro et al. 2003). These tools get information from previously embedded sensors. Through an expert system, this information is evaluated and results are represented as excel sheets or data graphs. If there is any deficiency in the system, it can be identified from these

eWork and eBusisness in architecture, engineering and construction

356

representations. These tools can only be useful in post-construction equipment tunings or post-occupancy system maintenance. The second trend of tools focuses more on testing specific equipment such as measuring the exhaust volume of a fan (Rossi et al. 2003). These tools evaluate the performance of specific type of equipment according to their function. They can only be used during the testing phase. We believe our proof of concept prototype will be different from both of these and support the embedded commissioning process during all of the building lifecycle phases. Neither of these described tools supports the specification or inspection phases of commissioning, two of the three main events of commissioning defined in our EC data model. In our EC process model and EC data model we observed that data evolves with the building lifecycle. During requirement specification, every piece of equipment has abstract definitions; whereas in construction and occupancy phases these definitions become detailed. At this time, we are in the process of mapping the EC data to specific tasks in the EC process model. We are designing the system architecture for our prototype and its fimctionalities through a group of use cases. In future work, we will implement this as a software application and test it on real time data sets. 6 SUMMARY OF FINDINGS AND FUTURE WORK We have described building commissioning as an important new area of practice and research in the industry. We noted that initially it emerged as the central ingredient of building delivery that is responsible for verifying design intent. We also recognized that in its current form building commissioning is rapidly becoming the choice for performance verification for HVAC systems and LEED certification. Finally, we argued for a computer based technology, called Embedded Commissioning that redefines commissioning as a persistent vehicle for verifying and validating design intent. We pointed out the important implications of this on the design delivery process: decision complexity, system integration and seamless processing. Furthermore, we reported on the work that we have been doing in two areas: (1) eliciting EC data from existing documents and processes in the field, and (2) designing a proof of concept prototype model of HVAC commissioning data and its transformation. Our future work envisions several additional activities: (1) completing and testing data modeling and exchange applications for the embedded commissioning of HVAC equipment, (2) exploring other areas of EC particularly in the facility management area, and (3) revisiting and refining the larger implications of EC on the entire building lifecycle process, particularly expanding the use of design intent and its tracking as a catalyst for upstream and downstream issues. REFERENCES Akin, O. 1978. How do architects design?. in J.C.Latombe (ed.), Artiflcial Intelligence and Pattern Recognition in Computer Aided Design: 65–104. New York: NorthHolland Publishing Co.

Embedded commissioning for building design

357

Akin, O. 2001. Ethical Decision Making. Web published class notes, all rights reserved by OmerAkin, School of Architecture, Carnegie Mellon University, Pittsburgh PA, 15213, USA. Akin, O., Turkaslan-Bulbul, M.T., Brown, S., Kim, E., Akinci, B. & Garrett, J. 2003. Comparison of ASHRAE guidelines with building commissioning practice, Proceedings of National Conference on Building Commissioning, May 20–22, California. American Society of Heating, Refrigerating, & AirConditioning Engineers, Inc. 1996. The HVAC Commissioning Process, Atlanta, GA. American Society of Heating, Refrigerating, & AirConditioning Engineers, Inc. 1996. ASHRAE Handbook HVAC Systems and Equipment, Atlanta, GA. Castro, N.S., Galler, MA. & Bushby, S.T. 2003. Using the virtual cybernetic building testbed and FDD test shell for FDD tool development. Proceedings of National Conference on Building Commissioning, California, May 20–22. Claridge, D.E., Culp, C.H., Turner, W.D. & Haberl, J.S. September 1998. Energy and comfort benefits of continuous commissioning in buildings, Proceedings of the International Conference Improving Electricity Efficiency in Commercial Buildings, Amsterdam. Davis, G. 1974. Applying a planned design process and specific research to the planning of offices, in D.H.Carson (ed.), Man-Environment Interactions: Evaluations and Applications—The State of the Art in Environmental Design Research: 63–89. Stroudsburg, PA: Republished Dowden, Hutchinson and Ross, Inc. Elowitz, K.M. 1994. Design for commissioning. ASHRAE Journal October: 40–7. Kao, J.Y. 1992. HVAC Functional Inspection and Testing Guide, Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce. Luskay, L. 2003. Identifying building design information necessary for commissioning and proper system operation. Proceedings of National Conference on Building Commissioning. 20–22 May, California. Piette, M.A., Kinney, S. & Haves, P. 2001. Analysis of an information management and diagnostic system to improve building operations, Energy and Buildings 33(8): 783–791. Reilly, J.C. Jr. 1975. Ships of the United States Navy: Christening, Launching and Commissioning, Second Edition. Washington, DC: Naval History Division of the Department of the Navy. Rossi, T.M., Douglas, J.D. & Bianchi, M.VA. 2003. Evaluating and documenting the performance of unitary HVAC equipment with the Honeywell HVAC service assistant, Proceedings ofNational Conference on Building Commissioning, 20–22 May, California. Wang, H., Akinci, B., Garrett, J., Akin, O., TurkaslanBulbul, M.T. & Gursel, I. 2004. Towards DomainOriented Semi-Automated Model Matching for Supporting Data Exchange, Proceedings oflnternational Conference on Computing in Civil and Building Engineering, June 02–04, Weimar, Germany.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

The development of a technical office organization structure for enhancing performance and productivity in fast track construction projects T.A.H.Barakat, A.R.J.Dainty & D.J.Edwards Department of’ Civil and Building Engineering, Loughborough University, Leicestershire, UK ABSTRACT: The success (or failure) of any construction project is inextricably linked to the quality, accuracy and timely delivery of design and production information. For large fast track schemes, the management and coordination of this information amongst the project team is particularly problematic because information, is required more rapidly than on traditional projects. This paper reports on seminal research, which developed a new theoretical organization structure to cope with the onerous demands for information on fast track schemes. It proposes the creation of a new information centre termed the “Technical Office” (TO). The organization structure differs from traditional organizational models as the TO concentrates on tasks rather than functions to achieve: enhanced communication; greater flexibility to respond to changes and adapt accordingly; and concurrent engineering. The TO structure was tested on a large industrial project in the United Arab Emirates (UAE). The project was the Industrial City-Contract 2B with a value of approximately 15,000,000 USD, which consisted of 49 buildings, including precast elements and a complex electro-mechanical system. The initial results of the analysis were encouraging.

1 INTRODUCTION The success (or failure) of any construction project is inextricably linked to the quality, accuracy and timely delivery of design and production information. For large fast track schemes, the management and coordination of this information amongst the project team is particularly problematic, because information is required more rapidly than on traditional projects. Fast track processes are designed to reduce project duration by overlapping project phases and performing them in parallel as much as possible. Large reductions in project durations have been achieved by applying fast track processes. However, many organizations are having difficulty to successfully implement fast track processes and realizing their benefits. (Ford, D.N., 2000). Two of the principal explanations for failures to implement fast track processes are: (1) the failure to match the organization’s people, controls, tools, work into smaller pieces. Fast track processes increase process and management complexity Process design

The development of a technical office

359

and management policies failed to address processes and structure with its need for efficiency, focus, incremental change, radical innovation and proficiency, and (2) the effects of disaggregating the increased complexity inherent in fast track processes and this has been a reason for failure to realize the potential to reduce project durations (Ford, D.N., 2000). The aim of this paper is to outline an organizational system that would align the structure, process, controls and people with the need for efficiency, productivity, flexibility, innovation, proficiency and adaptability A new organization structure which aligns the dependent variables crucial to project success on fast track schemes is proposed (termed the “Technical Office”) which demonstrably leads to improved outturn performance on these types of projects. The paper deconstructs the various facets of effective organizational structures and outlines the benefits of the TO in addressing each area. This is put into context through a case study project which demonstrably shows the benefits that the TO can bring. 2 ORGANIZATIONAL STRUCTURE Baccarini (1996) states that organizational complexity may be defined by differentiation and interdependency. Organizational structures are more complex when the differentiation of the parts is greater. Differentiation has two dimensions: vertical and horizontal. Vertical differentiation refers to the number of levels in the organization, where more levels indicate more complexity. Horizontal differentiation has two parts: organizational units such as departments or groups, and task structure, which refers to the division of tasks. The second attribute of organizational complexity in projects is the degree of operational interdependencies and interaction between the organizational elements. The construction industry has displayed difficulty in coping with the increasing complexity of construction projects. Complex prqjects demand an exceptional level of management, where conventional systems developed for ordinary projects have been found inappropriate. Complex projects require that differentiation and interdependencies are managed by integration (i.e. coordination, communication and control). This is particularly true of construction prqjects, which are typified by strongly differentiated but largely interdependent parts (Baccarini, 1996). It may be the mindset of the construction industry that complex projects require complex organizations, but this is far from certain. To answer the question of which structure suits large and complex projects it is best to start with a basic management model. An accepted model shows five main phases in the management cycle: planning, preparation, execution, reporting and control. The first two phases logically fit together, and they provide the requirements for the execution phase. The last two phases of reporting and control also fit together. Those planning and preparing are best suited to report and control the execution phase. With this in mind, the structure may be divided in two main parts. Figure 1 shows the main structure, which is the basis for the development of the “Technical Office” (TO) concept. The concept is to have all tasks for each phase in the project, and resources required to perform them, within each part of the structure. The execution phase would be performed by the site management team. The planning and preparation phase would be performed

eWork and eBusisness in architecture, engineering and construction

360

by the TO While execution is under way the actual versus planned is continuously monitored by the TO for reporting to the Project Manager and for control of activities. Administration provides overall

Figure 1. Technical Office organization structure. support for the project Within this would lie human resources, accounting, etc. This structure provides some advantages that may not be obvious at first glance. The literature recommends that project organization structures should be hybrid type, flat and decentralized, flexible and responsive to changes, reduce fiinctional barriers, improve communication and achieve coordination and concurrency. The TO achieves all of these requirements. The benefits of the TO are discussed below in relation to the essential facets of effective project management organizational systems, before the practical implications are explored through its application to a case study project. 2.1 Organic structure Anumba et al (2002) recommend that integrated team structures be implemented at the project level. Layered or bubble structures are recommended as they are more flexible than matrix and team structures. These types of structures are recommended as they provide greater flexibility and improved communications. This is in agreement with Nikolendo and Kleiner (1996) who state that more companies operating in dynamic and unstable environments are adopting organic models. Organic models are characterized by openness, responsiveness, and lack of hierarchy. The TO stmcture is such an organic type structure. It is not a functional/divisional structure and not a matrix or team structure. It is an organic structure based on the phases of the management cycle. Within this structure is the multi-disciplinary team based on a common objective and without any fiinctional disruptions. In this manner we get a lean system that is flexible and robust. The realization that traditional structures were unsuitable led to the development of more flexible structures. These are flat and decentralized and characterized by lateral communication and wide spans of control. These organizations are intended to promote teamwork and collaboration, which is required to implement concurrent engineering.

The development of a technical office

361

Additionally, construction projects are highly volatile. That is, the tasks required to be performed in a given project are variable and low in analyzability. The tasks are largely non-routine, and the task process does not consistently remain the same over time (Shih and Tseng, 1996; Pena-Mora and Li, 2001). In this setting, the organization structure needs to be flatter and more decentralized than traditional structures. The flatter structure permits greater information processing among all members. In the face of task uncertainty, providing relevant information enables managers to make better decisions (Dibrell and Miller, 2002). Barber et al (1999) state that by granting more autonomy to segments of a complex operation, better utilization of local knowledge is gained. Additionally, quicker responses to needs and improved motivation are achieved. The TO provides a flat and decentralized structure. The intent is to minimize the length of both vertical and horizontal communication. Communication should be achieved across the shortest possible route. Therefore, there are only three levels vertically within the structure. Additionally, the length of horizontal communication is minimized within each of the divisions and amongst them. This is particularly important within the TO whose tasks are largely variable, non-routine and low in analyzability. Also, communication is unhampered across the divisions as each is reliant on the other. In effect, each division is provided its autonomy to manage itself. This would be required to handle the largely non-routine tasks in a suitable manner. It is also necessary to allow each division to manage the tasks within its phases. 2.2 Reduce functional barriers The organization should not be centered around functions, but should be centered on tasks. These tasks need to be performed in accordance with the management phases stated previously. In order to perform tasks for construction projects, team members should come from a variety of disciplines in order that all aspects of the project are dealt with (Evans et al, 1994). Members totally committed to the team and have no allegiances to functional departments help overcome many of the potential team problems (Prasad, 1995). Underlying the “team” is the requirement to be decentralized within the organization structure. Decentralization means the need to empower. Empowerment is stated as providing flexibility and tolerance of diversity from an implementation model developed mainly for contractors. However, it gives senior management the retention of ultimate business control. It is also shown that empowered employees are provided the required resources and autonomy to strive for innovation and to be able to respond to change (Holt et al, 2000). The TO concept is centered around the tasks required to be performed during the phases each unit is responsible for. It dissipates all functional allegiances and establishes a multi-disciplinary team that is focused on achievement of the same objectives. In addition, the TO organization is necessarily decentralized, and hence, the requirement for employee empowerment to perform the tasks required in the manner best suitable for them. That does not mean allowing “loose ends” as control is maintained by senior managers. This results in a more dynamic model. This is important as there are many changes that occur during a construction project. These changes come for a variety of reasons and from a variety of sources, internal or external to the organization. Some of these changes may be anticipated. That is, as an inevitable consequence of the

eWork and eBusisness in architecture, engineering and construction

362

construction process itself (common cause variations). Others may not be foreseen (special cause variation) (Cox et al, 1999). The phenomena of construction delays and overruns, a critical function in construction projects, is expected to continue unless management actions are taken to control the causes within the planned element of the design and construction works. Good management practice in planning, coordination, and a change in control procedures need to be recognized and its implications understood (Al-Momani, 2000). In fact, the project organization’s responsiveness may be inhibited by its organizational structure (Love et al, 2002). The TO is highly flexible and has the ability to respond to changes as they occur. 3 COMMUNICATION Late project information is a primary cause of quality problems on site (Bentley, 1981). Cornick (1990) states that two thirds of construction problems are caused by poor coordination and inefficient means of communication of project information and data. This results in delays and incorrect decisions being made. This communication problem is compounded by the large volumes of information and documentation produced. Turk et al (1994) estimate that the number of documents produced in a single building structure may be in the order of 10,000, most of which are stored on paper. The construction process demands proper and timely management of project information and documentation. The improvement of the communication process in projects is essential. The key requirement to achieve this is coordination of information exchange. Even though the technology is available, the development of an improved communication and data system to meet the needs of the various parties in the project has to be done first. (Rojos and Songer, 1999). Collaboration and coordination is required with data and information exchange between dozens of companies. These companies work together to achieve a common project goal, many times located in different geographical locations. The implementation of construction projects involves thousands of activities requiring hundreds of different resources. These activities trigger information intensive processes during the construction phase. Additionally, construction projects are dynamic and subject to change during its life cycle. There are many factors affecting the implementation of a construction project. These include technologies, inhibitors and internal or external constraints may lead to changes. These changes must be communicated to all those concerned or affected by them in order to enable them to make necessary modifications and changes to the project according to the new situation. The amount of information generated during the implementation of a construction project is immense. An efficient and effective system to manage this information would affect the project’s cost, time and quality (Soibelman and Caldas, 2000). Information is strongly linked to activity. It enhances the ability to act, and activity creates information. Therefore, information is a crucial element in the enhancement of any organizational process, and timelines, accuracy relevance and quality are requisites of information. Contingency Theory (Galbraith, 1973) states that there is no best way to organize but different methods of organizing are not equally the effective. Different

The development of a technical office

363

organization structures and networks of information flows will probably have diiferent effectiveness and efficiencies. In order to achieve better effectiveness and efficiencies of the process, the organizational structure and the network of information flows have to be closely linked. Additionally, the fragmented nature of the construction industry results in a lack of a central project information repository and the lack of effective cross-discipline communication within the project team. This reinforces the confrontational culture common in construction projects (Sun et al, 2000). Figure 2 shows a macro view of the communication process in construction. It is very erratic and not channeled. Dawood et al (2002) proposed a framework for a central information repository as shown in Figure 3. The Technical Office concept is in agreement with the requirement for a central information repository. However, this repository is best suited to be with the contractor and the modified diagram would be as shown in Figure 4. The TO would then be the information center for both the contractor and the parties involved. The TO is suitable because the contractor is responsible for bringing aboard all subcontractors, suppliers, vendors, etc. to plan, prepare, and execute the project in a timely manner and within quality standards. This would provide the shortest communication channel to all parties. Additionally, the contractor is responsible for planning and preparation of all construction documents (e.g. shop drawings), which can be completed only with the input of subcontractors, suppliers, vendors, etc. who are in contractual agreement with the contractor. The contractor receives all information, coordinates them and distributes the construction ready information. The TO allows for the flexibility to organize and change based on the team within it and the requirements expected. This flexibility to organize and change is enhanced by the fact that there is a single information center. This information center allows for better informed managers, which allows for better decisions being made. Additionally, the management phase cycle concept will not allow for loss of control as the division of phases provides a “push-pull” balance.

Figure 2. Macro view of the communication process.

eWork and eBusisness in architecture, engineering and construction

364

Figure 3. Proposed framework (Dawood, N. et al, 2002).

Figure 4. Macro view of proposed TO. 3.1 Production information Nambayashi et al (2000) divided production information into two main parts: principal information and miscellaneous information. Principal information in construction projects are defined as information of drawings and construction planning, which provide construction “products” and “process”. Miscellaneous information processing is defined as the work required for confirmation and adjustment of principal information, and was described as “production control information”. It was found that 73% of work hours of

The development of a technical office

365

the general contractors’ staff was spent for confirmation and adjustment of principal information. This is contrary to the importance of the information! The multi disciplinary characteristic of a construction project makes it necessary to include representatives of domain-specific backgrounds within the team. The initial design will be the basis for development of detailed design for each discipline. Each discipline develops its components of the overall design. This may seem as logical and correct. However, this only provides for local optimization (i.e. of components), but may well be sub-optimal for the whole process. According to Galbraith (1973) this may be interpreted as the creation of self-contained tasks and is an information reduction strategy Interdependencies always occur among components and decisions have to be made considering the best solution fitting all disciplines’ requirements (global optimization). This process may be termed as “coordination”. Most of the design related problems occur where interdependencies between components are. Therefore, to achieve an optimal global solution, not only should information and knowledge be shared, but they should also be managed in a manner that actively promotes integration (Nambayashi et al, 2000). The TO, as the information center responsible for the planning and preparation phases takes the initial documents and transforms them to production information capable of being executed. It receives all information from all sources required to produce the production information. The production information will consider the best solution fitting all disciplines’ requirements since there are no ftmctional barriers established within the team, and they are working to a common objective. Additionally, all interdependencies are known and coordination will be required of all information received. 3.2 Information, uncertainty and iterations As was alluded to above, construction projects face a high degree of task uncertainty. Task uncertainty may be defined as “the difference between the amount of information required to perform the task and the amount of information already possessed by the organization” (Galbraith, 1973, p. 5). Therefore, task uncertainty requires information to close the gap between information available and information required, thereby enabling the achievement of the task. Galbraith (1973, p. 4) states, “the greater the taskuncertainty, the greater the amount of information that must be processed among decision-makers during task execution in order to achieve a given level of performance”. Information flows are of primary importance in project planning and execution and serve a dual purpose. First, they provide a clear picture of the ongoing project on a real-time basis. This enables decision makers to monitor and control activities and to make corrective actions when required to meet planned milestones, schedules and budgets. Secondly, information flows between informatively linked activities may modify or affect the other when information is generated from it. Untimely information flow change requirements and resources availability, and hence affects activities completion time or execution. Overall project quality depends upon the possibility and capacity to implement corrective actions in order to minimize the consequences of errors and accidents, thereby, avoiding an unplanned iteration in the project. However, the more two activities are informatively linked, the more an unplanned iteration of one of them affects the other, and the overall execution of the project. The more two activities are informatively linked;

eWork and eBusisness in architecture, engineering and construction

366

the more important it is to execute them concurrently. This is supported by the definition of concurrent engineering as “a methodology to schedule concurrent activities which share common conceptual tools and information resources” (Nicolleti and Nicolo, 1998). A major reason that enterprises react slowly and inflexibly is the sequential process of product development. Departments act rather independently, and thereby, do not know the demands and capabilities of each other. Generally, information and communication systems support sequential rather than concurrent workflow. They are able to handle documents and exact information. Partial information and uncertain and incomplete information are not supported by these systems, even if they contain important and valuable information for succeeding activities. In the early stages of product and process development, this type of information is typical. It contains constraints and determines the main part of the development process. The benefit of this additional information is its capability to reduce the number of iterations, thereby reducing the time between the creation and use of information. Making information available early means that costly iterations can be avoided, and this is relevant for parallelism. In current processes the document structure restricts the concurrent development of activities since information is collected in documents and passed on. Recipients of the documents usually require a small fraction of the information in a document. However, the need for small pieces of information for successive activities is neglected. Small and flexible information units can be passed on and used very early, which advance the feedback to assess results and to actualize knowledge bases (Eversheim et al, 1997). The impact of concurrence on performance is asymmetric because effects of unplanned iteration cycles increase as projects become more concurrent. Errors generate additional work and iteration cycles as concurrency is increased. Additionally, the average iteration path length is increased with increased concurrence by delaying the discovery of the need for rework to phases farther from the generating phase. The failure to achieve the full potential of fast track processes stems from processconstrained progress magnified by concurrent development practices. Iteration cycles increase duration even with availability of ample resources since the process is constrained by the underlying recursive structure of information exchanges. Iteration cycles delay projects by being more in number, longer in the distance which information must travel, slower in traversing that distance and occurring later than possible. With increased concurrence, development processes become more difficult to manage. Managers generally have more influence on resources than processes, and thereby, have few effective tools and methods to accelerate with when iteration cycles constrain progress (Ford, D.N., 2000). Williams et al (1995) term the iteration process in a project for design and manufacturing of a vehicle as the “vicious circle of parallelism”. The design process where the design of cross-related parts of the product occurs concurrently causes the design activities to take longer as each part affects the other(s). This causes delay, and with time limitations, the project becomes more concurrent as delayed activities overlap succeeding non-delayed activities in order to attempt completion within project duration. Even though this effect may be accounted for during planning, the process becomes nonrobust. A change in one element causes a loop to be set up where the tight time scale causes more parallelism, which increases cross-relationship between activities, thereby

The development of a technical office

367

increasing activity durations and results in increased delay resulting in even more parallelism. This situation is self-perpetuating. However, there are further loops that accelerate this loop. Increased cross-relations between parallel activities implies difficulty in freezing the system as a change in one component will aifect other components. Without a system freeze, and within time limitations, management is forced to work on items where the surrounding parts are yet not frozen. This has two main effects. The first is that it demotivates the design staff who work with unclear parameters and know that their work may be done in vain. The second and more important is that the design of such components may have to be reworked if any changes are made to any of its cross-related components. The TO, as the information center of the project, has several advantages regarding the information flow and achieving concurrency. Firstly, the TO has the responsibility to get the information and transform that into production information in a timely manner and in the required quality. Therefore, the TO would know the information needs to complete its tasks and the information dependencies between tasks. The TO would strive to get the information required in a timely manner as they have prepared the planning and know the needs. In addition, it would know what information can be delayed and when it is required to execute the plan. Also, all information required for the completion of dependent tasks would be known. This would provide the ability to achieve a higher degree of concurrency as all required versus available information is known, as well as the time frame they are required in. Secondly, the iterations of information across phases is minimized. The TO, as the information center and the unit that plans and prepares all production information, provides for all iterations of production information within a single multi-disciplinary team setting. This would provide for better manageability of these iterations and distribution of production information, which would minimize rework considerably. Thirdly, the TO is able to issue smaller units of information required for the execution phase. The TO would not necessarily wait for all information required to complete all systems when only a fraction of the information is required for execution. 4 CASE STUDY PROJECT The case study project was the Industrial City-part B, which was a $15,000,000 project in the U.A.E. The project was one of five simultaneous projects awarded to a variety of contractors. The largest contract was the case study project. This was a good opportunity to compare performance against other contractors in a project of similar nature. The TO was organized in the manner shown in Figure 1. The structure was based on the management cycle model. The fiinctions were dissipated and concentration was on tasks to be performed within the respective phases. It acted as the information and production center for all parties involved in the project. The TO was responsible to get all information required from all parties including consultant, subcontractors, etc. to ensure that all production information required for a given task is made available in a timely manner. The information is then coordinated between informatively linked tasks in order to ensure that there are no discrepancies. At times the site team would require specific information related to complete systems. An example is the electromechanical openings

eWork and eBusisness in architecture, engineering and construction

368

in the structure. The TO would provide this information to the site team, even though not all information for the complete systems was available. The importance was to minimize any uncertainties within the information given in order to avoid rework. The TO achieved this objective. The TO performed effectively in the planning and preparation phases in the project. This resulted in full knowledge of what information was available, what was still required and when, what information was required for informatively linked tasks and ensuring that they were coordinated to achieve optimal production information. The TO was also able to minimize the iterations of information in two ways. Firstly, any information missing was sought from the parties providing it. If the site team required partial information, it was provided to them, but complete systems were delayed until all information was provided, at least to a certain degree of certainty, but as not to allow any delays to the project. In essence, a system freeze was only made after information was gathered and coordinated, but before the planned date. Secondly, the informatively linked tasks were clear within the planning and preparation. Additionally, the multi-disciplinary team made all information required and all links known. The tasks would be completed only after getting all the information and coordinating them. This was instrumental in reducing iterations of information and achieving a higher level of concurrency. The TO was demonstrably flexible and adapted well to changes occurring. If a change was made, the TO would immediately set out to clarify what information was required versus what was available. Again, any missing information was sought after and all effects of the change were coordinated with all other tasks and any changes were made in new production information, which would subsequently be distributed to those concerned. The effects of the change would be included in the planning as well. From the above it was found that the TO performed well in terms of time, cost and quality, even when compared to the other contractors in the project The TO was able to save time by minimizing the iterations of information and providing coordinated production information. Rework was minimized and cost overruns were largely nonexistent. Quality was just a result. The staff were largely content with the system. They were quite motivated by seeing the outcome of their work. They were also happy that they worked in a decentralized environment in which they were providing suggestions and making decisions within the tasks they were working in. They brought attention to many problems that could have been overlooked. The multi-disciplinary team setting in the TO, with no functional allegiances, made them work together to perform their tasks, resulting in large amounts of information within the team and a great learning process at the same time. 5 CONCLUSION The TO concept provides a simple organization setting for complex fast track projects. The concept is based on the phases of the management cycle. This allows for an organic type structure, which would enhance the productivity and performance of construction projects. It also provides for a multi-disciplinary team who share a common objective. The communication is also enhanced by controlling the information coming in and out. It also manages the iterations of information, which is a problem in large fast track projects,

The development of a technical office

369

depriving the use of concurrent engineering at a higher degree. With all of the above many of the problems faced in construction projects may be minimized or alleviated. 6 FURTHER RESEARCH The TO concept was created based on the pilot case study performed. Research is still ongoing to develop the TO concept further. It is then to be tested in a fast track project. The results will be compared to baseline performance measures to be devised. The parties in the project will also be interviewed across the life cycle of the project for their input. REFERENCES Al-Momani, A.H. “Construction Delay: A Quantitative Analysis.” InternationalJournal ofProject Management, 18, 2000, pp. 51–59. Anumba, C.J., et al. “Organisational Structures to Support Concurrent Engineering In Construction.” Industrial Management and Data Systems, 102/5, 2002, pp. 260–270. Baccarini, D. “The Concept Of Project Complexity-A Review.” International Journal of Project Management, Vol. 14, No. 4, 1996, pp. 201–204. Barber, R, et al. “Decentralized Site Management-A Case Study.” International Journal of Project Management, Vol. 17, No. 2, 1999, pp. 113–120. Bentley, M.J.C. (1981), Quality Control On Building Sites, BRE Current Paper 7/81. Building Research Establishment, Gartson. Cornick, T. (1990), Quality Management for Building Design, Butterworth Architecture Management Guides. Cox, I.D., et al. “A Quantitative Study of Post Contract Award Design Changes In Construction.” Construction Management and Economics,Vol. 17, 1999, pp. 427–439. Dawood, N., et al. “Development of Automated Communication of System For Managing Site Information Using Internet Technology.” Automation In Construction, 11, 2002, pp. 557–572. Dibrell, C.C., and Miller, T.R. “Organization Design: The Continuing Influence Of Information Technology” Management Decision, MCB University Press, Vol. 40, No. 6 (2002) 620–627. Evans, S., et al. (1994), “Concurrent Engineering-Key Implementation Issues”, Advances InAgile Manufacturing, pp. 89–92. Eversheim, W., et al. “Information Management For Concurrent Engineering.” European Journal of Operational Research, Vol. 100, 1997, pp. 253–265. Ford, D.N. (2000) Impacts of Fast Track Processes on the Discovery of Changes. Proc. Of the Eighth International Conference (ICCCBE-VIII), 1078–1085. Galbraith, J. (1973), Designing Complex Organizations, Addison-Wesley, Reading, MA. Holt, G.D., et al. “Employee Empowerment In Construction: An Implementation Model For Process Improvement.” Team Performance Management, Vol. 6, No. 3/4, 2000, pp. 47–51. Nambayashi, K., et al. (2000), An Actual State and a Prospect of Computer and Network Application for Transferring and Sharing Information among Participants of Building Construction viewing from the job site in Japan. Proc. Of the Eighth International Conference (ICCCBE-VIII), 138–145. Nicoletti, S., and Nicolo, F. “A Concurrent Engineering Decision Model: Management of the Project Activities Information Flows.” InternationalJournal ofProduction Economics,54, 1998, pp. 115–127. Pena-Mora, F, and Li, M. “Dynamic Planning and Control Methodology for Design/Build FastTrack Construction Projects.” Journal of Construction Engineering and Management,

eWork and eBusisness in architecture, engineering and construction

370

January/February 2001, pp. 1–17. Prasad, B. (1995), “Is Planning A Strategic Requirement For CE Success?”, Concurrent Engineering: Research and Application, Vol. 3, No. 3. Rojas, S.R., and Songer, A.D. “Web-centric System: A New Paradigm for Collaborative Engineering.” ASCE Journal of Management In Engineering, Vol. 15, No. 1, 1999, pp. 39–45. Shih, H.M., andTseng, M.M. “Workflow Technology-Based Monitoring and Control for Business Process and Project Management”, Vol. 14, No. 6, 1996, pp. 373–378. Soibelman, L., and Caldas, C. (2000), Information Logistics for Construction Design Team Collaboration. Proc. Of the Eighth International Conference (ICCCBE-VIII), 341–348. Sun, M. et al. (2000), Integrated Information Management and Exchange for Water Treatment Projects. Proc. Of the Eighth International Conference (ICCCBE-VIII), 130–137. Turk, Z., et al. (1994), Document Management Systems As An Integral Step Towards CIC., Workshop on Computer Integrated Construction, (Helsinki, Finland). CIB Rotterdam, pp. 22– 24. Williams, T., et al. “Vicious Circles of Parallelism. “International Journal of Project Management”, Vol. 13, No. 3, 1995, pp. 151–155.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Innovative production planning system for bespoke precast concrete products V.Benjaoran, N.Dawood & R.Marasini Centre for Construction Innovation Research, University of Teesside, Middlesbrough, UK ABSTRACT: Bespoke precast concrete products are increasingly becoming major components of construction projects. This is mainly because offsite prefabrication and production offer a unique opportunity for innovation and cost savings for construction projects. The workload in the precast industry is a complex combination of uniquely and identically designed products, which have various delivery dates. The production process from design to manufacturing contains uncertainties due to many factors such as: multi-disciplinary design, progress on construction site, and requirement of costly purpose-built moulds. In this context, this research is aimed to improve the efficiency of the process by addressing the production planning because it has a significant impact to the success of the business. An innovative planning system and its prototype called ‘Artificial Intelligence Planner’ (AIP) is being developed. The manufacturing process model is mathematically formulated according to current practices, characteristics and scheduling logics. Two artificial intelligent techniques: Genetic Algorithm (GA) and Neural Network (NN) have been implemented in AIP to enhance data analyses and decision supports for production planning. GA is used in the optimization to search for optimal schedules and NN based estimation is applied to estimate the processing time required for any individual unique product design. The outcomes of the research include shortened customer lead-time, optimum factory’s resource utilization, and in-house repository of production knowledge.

1 INTRODUCTION The precast industry is a major supplier of offsiteprefabricated components to the construction industry. The construction of a building can be regarded as an assembly of hundreds of different designs and delivery dates of ‘bespoke’ precast concrete components. This demand creates the difficulty in the bespoke precast production. ‘Bespoke’ precast production system is in ‘make-to-order’ or ‘engineer-to-order’ style (Ballard et al., 2002). ‘Bespoke precast production’ has a major distinction from ordinary ‘mass production’ that every time the process is start from new product design. The complexity of bespoke precast production is based on this ground. Since the production is less uniformity, the ‘learning curve’ is hard to establish and the automation is hardly

eWork and eBusisness in architecture, engineering and construction

372

implemented to assist the process. The optimum resources utilizations are serious issues of precast manufacturers. Therefore, the production planning requires sophisticated managerial tasks and becomes a key of the success of the delivery program, customer leadtime competitiveness, and the effective utilization of purposed-built precast mould (Benjaoran and Dawood, 2003). The aim of this research is to develop a new (semiautomatic) planning system to manage bespoke precast production called the ‘Artificial Intelligence Planner’ (AIP). The AIP system and its components’ operations are separately described in different sections of this paper. The paper is mainly focused on the formulations of process and product models, which are applied to the bespoke precast production. 2 ARTIFICIAL INTELLIGENCE PLANNER (AIP)APPROACH AIP’s transactions start from gathering input data to finally arranging a production schedule. The system adopted artificial intelligence technologies: neural network (NN) and genetic algorithm (GA) to assist the difficulty of the production process. Figure 1 shows primary input data of the bespoke precast production process come from the external sources (project designers and contractors of construction projects). These are project drawings, product specifications, and construction schedule. The precast product design and delivery schedule are created to conform to both external input data.

Figure 1. An overview flowchart of the AIP planning system.

Innovative production planning system

373

The main production process includes product design, productivity estimation, production planning, and manufacturing. Two main AIP’s components called ‘Processing-Time Estimator’ (PTE) and ‘Production Scheduler’ (PS) are developed. PTE is assigned to assist the productivity estimation and PS is for the production scheduling tasks. The details of development of these two components are described in the following sections. Also, the AIP system implements data integration technology through the ‘Central Database’ to manage historical and current project data. The data in AIP’s transactions, therefore, current project data are integrated and consistent while historical data can be analyzed and used. The ultimate outcome of the system can be the high quality of precast products resulting from short customer lead-time, effective factory resource utilization, and satisfaction of delivery requirements. 3 PRODUCTIVITY ESTIMATION WITH ‘PTE’ The productivity estimation of precast manufacturing routines is a necessary task before being able to arrange a production schedule. A large variety of bespoke product designs results in requiring their own different manufacturing time. The task relies on estimators’ implicit knowledge, which is experience and intuition based. This current manual practice is person-dependent and difficult to transfer or share this valuable knowledge within the company. This study adopts two different techniques: neural network (NN) and multiple regression (MR) and attempts to formulate two productivity estimation models called ‘BPPE-NN’ and ‘BPPE-MR’, respectively. The outputs from BPPENN are compared with the ones from BPPE-MR. This is to verify the results and prevents errors made by either model. The outline of PTE is illustrated with a flowchart in Figure 2. The detail operations of PTE are related to the estimation models inside. The models are used to map the mathematical relationships between the productivity and its own influential factors. These relationships are built upon historical project data and are used to estimate productivity values of the new project. These mathematical relationships are updated regularly as the historical project data increase. The values of the influential factors that are taken from the new project are fed into both models. The outputs are the estimated processing-time values. 3.1 Formulation of bespoke precast productivity estimation Four precast manufacturing routines, namely ‘Moulding’, ‘Pouring’, ‘Demoulding’, and ‘Finishing’ (definitions are provided in Section 4.1) are considered in both models. The productivity of these routines is defined in terms of ‘durations’ for accomplishing the routines and these terms are the values to be estimated. A large number of these estimated figures can be demonstrated as an example of a construction project may require more than a hundred different designed products; each of them requires different ‘durations’

eWork and eBusisness in architecture, engineering and construction

374

Figure 2. A flowchart of ‘ProcessingTime Estimator’ (PTE). for those four routines. All these figures have to be estimated. 3.1.1 Productivity influential factors It is difficult to exhaustively determine all factors affecting labor productivity. Many productivity models have proposed different sets of these factors. Previous research studies (Russell (1993), Sonmez and Rowings (1998), AbouRiszk et al. (2001), Thomas et al. (2003), Srinavin and Mohamed (2003)) have considered influential factors largely based on the variation of the working environment (such as, temperature, site condition, or equipment setting, etc) regardless building designs. The reason is their models are for the construction tasks, which are executed on site. Yeh (1998) suggested that if an influential factor has a very small variation, their effects could be very small and could be neglected from a model. Although the precast manufacturing routines are basically similar to the construction tasks, they are executed in a more controlled working environment. In this way, a number of the influential factors could be removed. However, in the bespoke precast production, there is a large variation of product designs. The difficulties in product designs should contribute important influences. For this research study, twenty influential factors are identified mostly based on the difficulty and variation in their custom designs including product shape, materials, and manpower groups. The following sixteen factors extracted from precast product shop-designs are regarded with their product shape and materials: • Nominal height is the vertical dimension, nominal length is the longer horizontal dimension, and nominal width is the other horizontal dimension of a product. • Base area is the area that is on the bottom when a product is being cast. • Top surface area is the area that are on the top and do not contact with the mould. • Dropping area is the area that a panel has dropped its nominal height. • Finishing area is the area of concrete finishing area on the top surface area. • Tiling area is the area that is pasted with tiles. • Volume is the total concrete volume of a product. • Weight is a weight of a product calculated from concrete and reinforcement weight and all embedded parts’ weights.

Innovative production planning system

375

• Number of curves is the counting number of curve surfaces along a product’s shape; for example, a curve surface of a window, or a curve surface of a balcony • Number of embedded parts is counted from all embedded parts, which are not reinforcement, such as lifting-point and duct blockouts. • Concrete strength, and slump of the used concrete are determined. • Reinforcement weight, and number of different bar shapes are determined from the bar list table provided on a product design drawing. The other four factors come from manpower are the number of workers assigned to the four routines for manufacturing that product. The manpower information can be obtained from factory daily-reports (manufacturing booking sheets). Sample data-sets of 50 different precast products were collected from a leading bespoke precast manufacturer in the UK and used for designing architecture and evaluating performance of the models. 3.1.2 Neural network based model (BPPE-NN) The common practice of designing NN’s architecture is through trial-and-error. The first step is to develop the NN with a common architecture and rule-of-thumb settings, then evaluate the NN’s performance, and adjust the parameters to improve the NN’s performance. Finally, the ‘multi layer perceptrons’ (MLP) with ‘feed forward’ and ‘backpropagation train’ is selected as the BPPE-NN architecture. The BPPE-NN has fiill connection of three layers. The transfer function of ‘processing elements’ (PEs) is the hyperbolic tangent (tanh). The hidden layer with the optimum number of hidden PEs is 8. The input layer has 20 PEs for all of the influential factors, and the output layer has 1 PE for each estimated value. The model is divided into four networks for four estimated outputs. The final networks of BPPE-NN use the ‘momentum learning rule’ method with the momentum rate=0.7, the step size of output layer=0.2, and the step size of hidden layer=0.5. 3.1.3 Multiple regression based model (BPPE-MR) Bespoke precast productivity is also modeled using the multiple regression (MR) technique. The relationships between each productivity value and all influential factors are described by Equation (1) below: (i) where y is an estimated output variable; xt=a variable of an influential factor i; Ai=a linear coefficient; A0=a constant or an intercept; and n is the total number of influential factors. 3.2 Models’ performances The estimation performances of both models are measured with three statistical values, namely absolute percentage error (APE), mean square error (MSE), and correlation coefficient (r). The results from the model evaluation are concluded that both BPPE-NN and BPPE-MR are comparable. They can be implemented together as BPPE-NN will

eWork and eBusisness in architecture, engineering and construction

376

give more often precise estimated values while BPPE-MR will help cross examine or verify the results and to alert the fault extrapolation from BPPE-NN. However, the reliability of both models much depends on the exhaustiveness of influential factors, and an amount and the representativeness of historical data. In a long-term implementation, the BPPE-NN is based on a large amount of historical data. Its estimation performance is anticipated to be better and better because its ability to be generalized to match future cases. Also, the BPPE-NN supports the automation in the estimation process and integrates data to product design process. Precast manufacturers potentially benefit from the model through the more accurate but less effortfiil estimation. 4 PRODUCTION SCHEDULING WITH ‘PS’ The production planning is very complicated and has a high impact on time and cost of the production program; however, the current practice of production planning is much simplified by applying the earliest due-date sequencing rule. Precast concrete manufacturing consists of many repetitive routines and each product is independent with no obvious logical precedence required. Pioneering researchers (Chan and Hu, 2002; Leu and Hwang, 2001) have proposed new scheduling methods for precast manufacturing. They applied the ‘flowshop scheduling modeV on general precast manufacturing processes and used the GA approach for the optimization. This study has further developed the flowshop scheduling model particularly for ‘bespoke’ precast manufacturing named as ‘BP-FSSM’. It aims to improve the production planning technique using the flowshop scheduling and GA based optimization approaches. BP-FSSM has included moulds reuse consideration since types and available numbers of moulds have impacts to the production cost and time. The moulds are costly and purpose-built in a limited number. The PS system is connected with PTE and Central Database. PS is illustrated with a flowchart in Figure 3. The operations of PS start from details of new jobs (products) fed into the scheduling model. BP-FSSM has been formulated according to the current implemented method of crew organization. GA randomly arranges job sequences and then evaluates them with the multi-objective function in order to reach the optimum. This procedure is repeated numerous times until GA programming loop is terminated. The final job sequences are the best findings and they are then allocated into a factory’s timetable with regard to the existing workload. The outputs of PS are efficient production schedules and a decision support for utilizing factory’s resources such as moulds and manpower. Precast designers intend to make all products as identical as possible to reduce the product design effort and to economize the cost of moulds. Purposebuilt moulds made of timber are designed and prefabricated to be able to cast slightly different designed products. Different and identical designed products, which can be cast with the same mould type, are grouped as a same product family($). The moulds can be reused but these jobs cannot be cast in the adjacent sequence instead they need to wait until their family moulds are available (see Equation (2)). Planners have to decide the number of each mould type (X$) and trade-off between time and cost by arranging a good schedule that effectively and efficiently utilizes this constrained resource.

Innovative production planning system

377

Also, bespoke precast products are specified with delivery dates, which usually correspond to the construction progress on sites. Therefore, bespoke precast products even of the same project may have different delivery dates. Product delivery dates are treated as ‘due dates’ (dj). It is important that the production schedule must be attempted to satisfy all product delivery dates. Manufacturing process of a bespoke precast product consists of many routine tasks some of which are ‘directive’ and the others are ‘supportive’. The directive routines are the focus of the production planning

Figure 3. A flowchart of ‘Production Scheduler’ (PS). while the supportive routines are less concerned and their planning is derived from the master plan of the directive routines. The directive routines are activities associated with casting procedures. They are as the following in sequence: • Modifying—adjusting, reshape or resize the mould to fit another product design. • Moulding—cleaning the mould, reassembly, oiling of mould surfaces, and then placing all reinforcement cage, mosaic or tiling, fixing, conduits and other embedded parts into the mould. • Pouring—pouring, compacting and levelling of concrete. • Curing—leaving the concrete to harden through natural process. • Demoulding—stripping or removing the mould from the product after its concrete develops adequate strength. • Finishing—cleaning, checking or repair or finishing the product. These six routines are regarded as ‘machines’. In case m=6, they are namely Modifying (M1), Moulding (M2), Pouring (M3), Curing (M4), Demoulding (M5), and Finishing (M6). Some of characteristics are taken from the model proposed by Chan and Hu (2002). That are twenty-four hours of a working day are divided into working-time (Hw) and nonworking-time (HN); and the routines are defined as ‘pre-emptive’ and ‘non-pre-emptive’. Pre-emptive routines are ordinarily performed only on working-time. If they are not completed at the end of the day, they can be paused and continued on the next working day. They are M1, M2, M5, and M6 (see Equations (3) and (4)). Non-pre-emptive routines, M3 and M4, are special. The routine M3 must be finished within one working day. If it

eWork and eBusisness in architecture, engineering and construction

378

cannot be finished within the working-time, a limited overtime (HE), which is counted after the working-time, will be allowed; otherwise, the whole routine is postponed to the next working day (see Equation (5)). For M4, the no-wait condition is applied to since the routine must start immediately after M3 is finished. In addition, M4 can continue during the non-working time without any workers attending so that the overtime is not required on this routine. Another special condition for M4 is it has a capacity to process more than one job at a time (see Equation (6)). The industry survey reports that manufacturing workers are divided into three crews. One crew is assigned to perform Modifying (M1). The workers in this crew called ‘Joiners’ who have high carpentering skills. The second crew performs most of the routines, which are M2, M3, and M5, and the last crew performs M6. The three crews are working together to complete each product (or job). This crew organization method becomes the fundamental assumption for the flowshop scheduling formulation. The work-sequencing logics of the crews (therefore, the ‘machines’) are quite complicated and different from the basic assumption applied on the general flowshop scheduling model The first and the last crews use the same completion time equation as defined in Equation (3). The second crew behaves differently because anytime it has more alternatives to begin its consecutive task. After finish a task, its consecutive task can be M2, M3, or M5 of the previous in-progress product, or continuing the next routine on the current product (see Equations (2), (4) and (5)). More work sequencing logics are applied on this second crew of how it selects its consecutive task wisely. All characteristics of BP-FSSM’s routines are exhibited through their completion time, which are formulated in the following Equations (2)–(6). BP-FSSM includes the mould reuse consideration. The machine that starts occupying a mould is Modifying (Mj); and the machine that releases the mould when it finishes is the Demoulding (M5). Any job Jj on M1 needs to wait for an available mould particularly of its mould type ($). The start time of M1 of any Jj (C(Jj S, M0)) is expressed in Equation (2).

Figure 4. Gantt chart of BP-FSSM with mould reuse consideration (Equation (2))

Innovative production planning system

379

(2) where Jj,$=a job at the sequence j that uses mould family $;j=1, 2, 3,···, n; Mk=a machine number k; C(Jj, M0)=the completion time of job j on the machine 0 (therefore, it is the start time of the machine 1); C(Jj, M5)=the completion time of job j on the machine 5; {…}= the minimum value of {…}; Ay=for every y, where 1≤y<j; Jy,$=a job at the sequence y that uses the same mould family $ as Jj,$ does; the number of mould type $=X$. An example scenario shown in Figure 4 illustrates that job-ID 1 and 2 have slightly different designs so they can be assigned to use and share mould ‘A’; job-ID 3 and 4 use mould ‘B’; job-ID 5 uses mould ‘C’. While the factory has prepared one of mould ‘A’, two of mould ‘B’, and one of mould ‘C’ (XA, XB, XC=1, 2, 1, respectively). The planners have arranged a production sequence as job-ID 1, 3, 4, 2, and 5. From the Gantt chart, job-ID 2, which now is produced in the fourth sequence (J4), needs to wait until mould ‘A’ is released from job-ID 1 since there is only one mould ‘A’ available. Job-ID 3 and job-ID 4 can be cast in an adjacent sequence without waiting for mould availability because there are two of mould ‘B’s; Job-ID 5 has its own mould ‘C’ so that it can be cast whenever Mj is ready. The Gantt chart also shows the idle time of Mj caused by jobID 2 waiting; and the completion time ofjob-ID 2 (C(J4, M6)) conforming to the above Equation (2). For pre-emptive routines, they are performed within the working-time. If they are not completed at the end of the day, they can be paused and continued on the next working day. The completion time of pre-emptive M1 and M6, which are executed by the first and the third crew, respectively, on the twenty-four hour scale is expressed in Equation (3).

(3)

where C(Jj, Mk)=the completion time of job j on machine k; Jj=ajob at the sequencey j;j=1, 2, 3,…, n; Mk=a machine number k; k=1, 6; T=Max {C(Jj−l, Mk), C(Jj, Mk−1)}+Pjk; Pjk=the processing time of job j on machine k; 0≤Pjk≤Hw; D = integer(T/24); Hw=working hours per one working day; HN=non-working hours per one working day; HN=24-HW. Note: In case of M1, C(Jj, M0) was defined in Equation (2). The completion time of pre-emptive routines M2 and M5, which are executed by the second crew, on the twenty-four hour scale is expressed in Equation (4) below.

(4)

eWork and eBusisness in architecture, engineering and construction

380

where C(Jj, Mk)=the completion time of job j on machine k; Jj=a job at the sequence j; j = 1, 2, 3,…, n; Mk=a machine number k; k=2, 5; T#=PrecTime (D)+Pjk; Pjk=the processing time of job j on machine k; 0≤Pjk≤Hw;D=integer (C(Jj, Mk−1)/24); PrecTime(D)=Max-of-Day(D) {C(Jj,−1, M2), C(Jj−1, M3), C(Jj−1, M5), C(Jj, Mk−1)}; PrecTime (D+1)=Max-of-Day(D+1) {C(Jj−1 M2), C(Jj−1, M3), C(Jj−1, M5), C(Jj, Mk−1)}; C(J0, Mk)=0. Note: Equation (4) is different from (3) that it uses ‘Max-of-Day(D)’ and &=2, 5. For example of how the second crew decide to move to the consecutive task, or the application of Equation (4). To determine C(J3, M2), let C(J2, M2)=28; C(J2, M3)=30; C(J2, M5)=50; C(J3, M1)=27; P32=1.5. Therefore, D=integer(27/24)=1; Prec Time(1)=Max-of-Day(1) {28, 30, 50, 27}=C(J2, M3)=30. The reason is that although C(J2, M5)=50 is the maximum time among the choices, it is on the next day whilst the others are on the same day (D=1). As a result, C(J3, M2)=C(J2, M3)+ P32=30+1.5=31.5. For non-pre-emptive routine M3, it must be finished within one working day. If it cannot be finished within the working-time, a limited overtime (HE), which is counted after the working-time, will be allowed. Otherwise, the whole routine is postponed to the next working day. The completion time of M3 on the twenty-four hour scale is expressed in Equation (5). (5)

where C(Jp Mk)=the completion time of job j on machine Jc, Jj is ajob at the sequence j; j=1, 2, 3,…, n; Mk=amachine number k; k=3; T#=PrecTime(D)+ Pjk; Pjk is the processing time of job j on machine k; 0≤Pjk≤HW+HE; D=integer (C(Jj, Mk−1)/24); PrecTime(D)=Max-of-Day(D){C(Jj−1, M2), C(Jj−1, M3), C(Jj−1, M5), C(Jj, Mk−1)}; PrecTime (D+1) = Max-of-Day(D+1) {C(Jj−1, M2), C(Jj−1, M3), C(Jj−1, M5), C(Jj, Mk−1)}; and C(J0, Mk)=0.HE=overtime hours allowed per one working day. For non-pre-emptive routine M4, it will start immediately after M3 is finished. Moreover, it can continue during the non-working time without workers attending so that the overtime is not applied on this routine. Another special condition for M4 is it has a capacity to process more than one job at a time. The completion time of M4 on the twenty-four hour scale is expressed in Equation (6) as follows: (6)

where T*=Max{0, C(Jj, Mk−1)}+Pjk; k=4; 0≤Pjk≤HN.

Innovative production planning system

381

4.1 GA based optimization After BP-FSSM’s completion time is formulated, the model is tested through the optimisation process in order to find optimum schedules. Many quantitative ways are proposed to evaluate the performance of the flowshop scheduling model such as: •‘makespan’ (=C(Jn, Mm))—the total length of the production program (Johnson, 1954); •‘total flowtime’—the sum of the completion times ofalljobs(Rajendran, 1995); •‘total machine idle time’—the sum of machine idle time of all machines all jobs (Rajendran, 1995); •‘to tal tardiness and earliness’—the sum of all jobs’ penalty that are charged if a job is either later or earlier completed than their due date (Sung and Min, 2001). For BP-FSSM, two kinds of idle times are targeted and kept to minimum. The first is the time that a precast component (job) waits for a machine. There is a job queue behind the machine. This wasted time can be measured by the totalflowtime (TF). The other is the time that a machine waits for a job. A downstream machine is ready and unoccupied while a job is still being executed at the upstream machine. This waste can be measured by the total idle machine time (MI). Another important concerns for bespoke precast production are the successful delivery program to a construction project and to minimize the inventory expenses; therefore, the measurement of the total tardiness and earliness (TE) is also considered. These three criteria are combined and used for evaluating the BPFSSM’s performance. They are set as a ‘multiobjectivefunction’ of the optimization (minimization) and are expressed in Equations (7) to (9) below. (7)

(8)

(9)

where σ=a possible solution (a permutation of job sequence); j=1, 2, 3,…, n; k=1, 2, 3,…, m; Cj=the completion time of a job at the sequence j; dj=the due date of job sequence j; τj=the tardiness penalty rate for the job at the sequence j; εj=the earliness penalty rate for the job at the sequence j.

eWork and eBusisness in architecture, engineering and construction

382

4.2 Performance of BP-FSSM From the example tests of 30 jobs (a combination unique and identical product designs which stimulates the actual workload of bespoke precast factory), the GA based optimization on BP-FSSM gives better schedules comparing to using the earliest due date rule. The improvement according to the three criteria are around 25% TF; 30% MI; and 55% TE reduction. The reduction of these criteria terms means a factory can gain benefits from more efficient resource utilization (more occupied crews, equipment, and moulds) and also products are completed nearer (not too early nor too late) to their due date. From this improvement the factory could save production time and cost, and also can control the quality of product delivery services. BP-FSSM can be used as a decision support for making an efficient production schedule. Also, it can be an analysis tool to determine the optimum number of each mould type. BP-FSSM captures characteristics and work sequencing logics of the precast routines regarding the crew organization. 5 CONCLUSIONS The paper proposes an innovation production planning system for bespoke precast concrete products. The system is a decision support, which adopts artificial intelligence techniques: genetic algorithm (GA) and neural network (NN) to alleviate the complexity in bespoke precast production. The system consists of two components namely ‘Processing-Time Estimator’ (PTE) and ‘Production Scheduler’ (PS) which are integrated together through the Central Database. PTE assists the productivity estimation and PS assists the production scheduling tasks. The core operations of both developed components are performed through the product and process models. Therefore, the main content of the paper is on the formulation of bespoke precast productivity estimation and flowshop scheduling models. The outcomes of the system include shortened customer lead-time, optimum factory’s resource utilization, and in-house repository of production knowledge. This improvement can benefit to both precast concrete and construction industries. REFERENCES AbouRizk, S., Knowles, P., and Hermann, U.R. (2001). Estimating labor production rates for industrial construction activities. Journal of Construction Engineering and Management, 127(6), 502–511. Ballard, G., Harper, N., and Zabelle, T. (2002). “An Application of Lean Concepts and Techniques to Precast Concrete Fabrication” Proc. 10th Ann. Conf. Int’l. Group for Lean Construction, Gramado, Brazil, August 6–8, 2002. Benjaoran, V., and Dawood, N. (2003). “Development of an artificial intelligence planner framework for bespoke precast concrete production.” Proceeding of the llth Annual Conference of International Group for Lean Construction, Blackburg, Virginia.

Innovative production planning system

383

Chan, W.T., and Hu, H. (2002). “Production scheduling for precast plants using a flow shop sequencing model.” Journal of Computing in Civil Engeering, 16(3), 165–174. Johnson, S.M. (1954). “Optimal two- and three-stage production schedules with set up times included.” Naval Research Logistics Quarterly, 1, 61–68. Leu, S., and Hwang, S. (2001). “Optimal repetitive scheduling model with sharable resource constraint.” Journal of Construction Engineering and Management, 127(4), 270–280. Rajendran, C. (1995). “Heuristics for scheduling in flowshop with multiple objective.” European Journal of Operational Research, 82(3), 540–555. Russell, A.D. (1993). Computerized daily site reporting. Journal of Construction Engineering and Management, 119(2), 385–401. Sonmez, R., and Rowings, J.E. (1998). Construction labor productivity modeling with neural networks. Journal of Construction Engineering and Management, 124(6), 498–504. Srinavin, K., and Mohamed, S. (2003). Thermal environment and construction workers’ productivity: some evidence from Thailand. Building andEnvironment, 38(2), 339–345. Sung, C.S., and Min, J.I. (2001). “Scheduling in a twomachine flowshop with batch processing machine(s) for earliness/tardiness measure under a common due date.” European Journal of Operational Research, 131(1), 95–106. Thomas Ng, S., Skitmore, R.M., Lam, K.C., Poon, A.W.C. (2003). Demotivating factors influencing the productivity of civil engineering projects. International Journal of Project Management, 22(2), 139–146. Warszawski, A. (1990). Industrialization androbotics in building: A managerial approach, Harper & Row, New York. Yeh, I.C. (1998). Quantity estimating of building with logarithm-neuron networks. Journal of Construction Engineering and Management, 124(5), 374–380.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Process and information flow in mass customisation of multi-story housing T.Olofsson, L.Stehn & E.Cassel-Engqvist eBygg—Centre for Information Technology in Construction, Div of Structural Engineering, Luled University of Technology, Luled, Sweden ABSTRACT: This paper illustrates how the process and information flow might be accomplished between a manufacturer of prefabricated houses, a real state trustee and end-users, i.e. the holder of the tenant-ownership. The research question investigated is how the house manufacturers can adapt its manufacturing process after customers demand. By mass customisation and a large variation of the final product, houses/flats, can be produced with a standardised manufacturing process. Giving customers the opportunity to design their own apartment with internally possessions can be considered as a competitive advantage. The paper examines the possibility to use an IT system to support the design, manufacturing and customisation process instead of using traditional manually capacity for customers’ options. A case study shows that the IT support should mainly focus on the information flow between the manufacturers design and manufacturing process and the real state trustee sales process to minimize errors for an efficient manufacturing. Supply chain management advantages for all stakeholders are found in the concept of using a single source of information. The case study also shows the importance of adapting the information model to the actual building process and product structure and to balance the available options to customers’ needs and expectations.

1 INTRODUCTION The construction of timber frame houses has a long tradition in Sweden. The great majority of detached houses has timber frames and is manufactured in permanent factories by small and medium-sized enterprises (approximately 74% between 1990– 2002). By comparison, about 69% (down from 90% 20 years ago) of all housing starts in the US are stick built on site. The experiences from the detached house market, having had an open competition for a long time, indicate that an industrialized and processoriented production approach could have a potential also for the whole housing industry. This is supported by an extensive evaluation of the Swedish construction industry (SOU 2002), indicating that it is possible to reduce production costs in housing construction through industrialisation, customer orientation, and a more efficient construction process. Logistics and supply chain management (SCM) are demonstrated as disciplines with the potential to increase efficiency in the construction process (Agapiou et al 1998; Naim and

Process an information

385

Barlow 2003). In the large enterprise manufacturing industry, the supply chain concept has been one model for improvements in efficiency. Holistic production philosophies such as lean production, and comprehensive planning methods such as enterprise resource planning (ERP), which are supported by information technology (IT) based software systems, are used to manage parts of or the entire supply chain (Crowley 1998, Tarn et al 2002, Al Mashari et al 2003). The possibility of cross industry learning from the manufacturing to the housing industry is analysed in (Gann, 1996). The potential for improvements in the housing industry as well as the use of concepts such as SCM, lean production using IT supported ERP, applied to small and medium-sized enterprises (SME) have been pointed out by Stehn and Bergstrom (2002) and Bergstrom and Stehn (in press). This paper describes a case study on how mass customisation of prefabricated timber houses might be accomplished using an integrated information management system in the design, manufacturing and sales process of tenant owned apartments and how the manufacturing process can be adapted. It also investigates the needs of, and relations between, the different stakeholders in the process, e.g. between a manufacturer, a real state trustee and the finally holder of the tenant-ownership. 2 THE CURRENT BUILDING PROCESS The investigated SME company (Olofsson et al 2004, Cassel-Engqvist, in press) is a producer of timber frame multi-storey houses in Sweden. Fifty percent of the production is based on skeleton contracts with real estate trustees. This has been a deliberately strategy taken by the SME to achieve a solid economical base. The skeleton contract with the real estate trustee investigated is based on a few typical house layouts. The “simplified” tendering process only includes adaptation of the house layouts to the project in question (only minor changes of the principle design are allowed to keep a high production-cost efficiency), negotiation of price and date of delivery and setting up a list of options for the prospective holder of the tenant-ownership. This type of market segmentation, i.e., a predefined principle design targeted to a specific customer group in terms of flat layout etc. and specific or typical features are offered to the customers by options (extras), e.g., equipment, flooring and finishing etc. is reported in Stehn and Jonsson (1999).

eWork and eBusisness in architecture, engineering and construction

386

Figure 1. The manufacturing of multistorey houses in the investigated SME company. The detailed design, purchase and manufacturing process starts after the real estate trustee have sold approximately 30% of the tenants-owned flats. The detailed design phase delivers element and block drawings to the manufacturing units. The purchase department supplies the manufacturing process with raw materials and components. Most raw materials are delivered on call. However, many components are delivered via a procurement process that in many cases needs to be initiated long before the actual building contract is signed. The manufacturing process can schematically be described as (Fig. 1): 1 Manufacturing of buildings elements such as inner and outer walls, floors and flats roofs 2 The elements are assembled to building blocks 3 The blocks are completed with fittings and fixtures in kitchen, bedrooms and bathrooms such as wall papers, flooring, cabinets etc. 4 Finished building blocks are stored in the factory stock before 5 Transportation to the building site and

Process an information

387

6 Assembly of blocks to multi-storey houses. The current building process has a number of drawbacks: – Physical measures of electrical appliances and ventilation pipes that collide with construction details have caused problems in the production. The design of electrical and HVAC installations are made by subcontractors in 2D using symbols. – Quantity take-off from 2D drawings. Delivery inspection cannot be made on goods from supplier that uses 2D drawings for quantity take-off. – Lack of a common article numbering system. Problems in verification of delivery from supplier can sometimes occur due to the use of different article numbering systems. – Supply chain management. The planning of the supply chain has become more difficult to handle with increasing production rate and customisation. – Customisation. The handling of selected options such as surface finish (wall papers, flooring) and fittings is error prone. Information errors cause problems in the purchase and production process and must be corrected on the building site. Most of these issues are related to information management. Several isolated systems including handwritten notes are used in the current building process. The information is mostly informal, i.e., can only be interpreted and processed by human beings. In the next chapter we will propose a strategy to remedy the deficiencies in the information management flow. 3 STRATEGIES FOR PROCESS AND INFORMATION MANAGEMENT The research was conducted using a single, exploratory, case study research design. The building process can be divided into 4 distinct sub-processes: 1 Tender and design 2 Manufacturing 3 Supply chain management (SCM) 4 Sales and customisation Process 1–3 is owned by the construction company and the sales and customisation process is owned by the real estate trustee. Figure 2 shows a schematic view of the information flow between the different processes and involved actors. After the contract has been signed the real estate trustee initiates the sales and customization process of the residential houses. When 30% of the flats are sold, the start order (1) is given and the pre-production engineering work commence. The detail design delivers (2) bill of materials and design drawings to the manufacturing process which affect the stock balance and supply chain management (3) When production starts information of selected option (4) from the real estate trustee sales and customization process must be passed to the construction company in order to individually customize the tenant-owned purchased flat.

eWork and eBusisness in architecture, engineering and construction

388

Figure 2. Schematic view of the information flow, processes and actors. To get a supportive IT environment an information strategy that supports the business strategy of the company is needed. IT systems requires that the information is formal and computer interpretable. Hence, an adequate information model that’s supports the business needs have to be defined, (Ward and Griffith, 1996). The IT systems must also support a seamless flow of information over process and organisational boundaries. In an industrialised construction process, the focus is set on the manufacturing process. Therefore, a block oriented information model was chosen to support the manufacturing process in the factory, (Fig 3). Since the multi-storey houses are made of blocks it is easy to extend the product information model to a complete building information model, (Fig 4). The most important process requirements on the information system can be summarized as follows: 1 3D-design to enable automatic quantity take-off and collision detection between installations and structural design.

Process an information

389

Figure 3.

Figure 4. Building information model. 2 Information sharing with subcontractors. The design process will benefit if the installation design is integrated with the structural design. A number of check-points and design iterations can also be avoided if the two design processes are done concurrently. 3 Version management ofdesigned components. An important motivation for industrial constructions is the reuse of design components. Since flaws in the design can be rectified in the next constructions project, a new version of that component is created. Version management is also a key factor in any quality systems. 4 Information sharing with the real estate trustee. The customisation information on buyer’s selected options must be securely transferred from the sales organisation to the manufacturing process. 5 Supply chain management redesign. Handling of pre-production engineering, procurements, delivery on calls, delivery checks, stocks and the supply of material and components to the production units in the factory should be integrated. To find a single system that fulfils all the process and information requirements is hard. In the massproducing industry the design and manufacturing process is often in the handled by two separate systems, a PDM system (Product Data Management) and MRP/ERP system (Material/Enterprise Resource Planning). These systems are often integrated using a common product information structure.

eWork and eBusisness in architecture, engineering and construction

390

Since the case company had already decided to investigate in a MRP system (req. #5), the suggested solution was to complement the MRP system with a PDM system that would fulfil reqs. #1–3. To enable

Figure 5. Suggested IT support system. information sharing with the real estate trustee (req. #4) a simple web application was developed to demonstrate information sharing with the selected PDM system. Figure 5 shows the suggested IT support environment in the process view. Since the MRP system is designed to concurrently support the manufacturing process of many building projects, the PDM system is selected as a single source of information for a building project. Updates and change orders are made in the PDM product information model before the product structure of blocks is transferred to the MRP systems. The PDM system used, is an Internet-based database management system, developed by Enterprixe Ltd (Enterprixe 2002). The system stores all project data in a central database, to which project members have concurrent access over the Internet. Depending on access rights, users can view or edit information by loading data from the server to local software clients. The server keeps track of the modeling work and modifications by connected users, who can check out and check in parts of the project. The PDM system is also responsible for producing production drawing for element production and block assembly. The demonstration web client was developed by Avantra, (Avantra 2004) and includes an administration user interface to create option programs for each type of flat.

Process an information

391

The sales representative, or the prospective customer, can login and select a flat layout and surface material, fittings etc for each type of room from a list of options. When all the option are selected the information is transferred to the PDM system and stored in the product structure. The room id created in the design was chosen as the common identification. Figure 6 shows the web clients user interface.

Figure 6. Web clients user interface. 4 CUSTOMER ORIENTATION In mass production to the consumer market the customer is well defined. The situation for many builders is more complicated since the customer is not the end user. In this case the holder of the tenant-ownership is customer to the real estate trustee who is the customer to the builder. Still, the needs and expectations of the end users are important parameters for the industrialised builder since the success for a particular building system depends on satisfying both the real estate trustee as well as the end user. An in-depth qualitative interview study was performed with two employees (selected on the basis of their special knowledge) of the real estate trustee. A quantitative survey followed by a qualitative interview of ten tenant owners of a newly built residential area was also performed. The aim was to identify customers’ needs and expectations to find the requirements and demands on the sales process and the information flow (4) in Figure 2. Both the real estate trustee and the tenant owners considered the possibility to select surface materials, fittings etc. as important. The investigation also showed that the

eWork and eBusisness in architecture, engineering and construction

392

experienced quality of the workmanship was an equally important parameter. Scratches, dents and marks from nail machines influenced the experienced quality in a negative way. When the tenant owner was asked to rank the different parameters, the following list of preferences was established: 1 Quality of workmanship 2 Options in the kitchen and bathroom 3 Options in other rooms The interview also showed that the real state trustee was interested in purchasing and installing some of the offered options themselves, such as kitchen fixtures, cupboards and white goods. Regarding the administration of the options programme, the real estate trustee was most in favour of using the web client. They saw obvious advantages in administration of the options selection procedure and facilitated communication with the case company. However, 90% of the interviewed tenant owners could not imagine to making the selection only based on picture on a web page. They were of the opinion that they wanted to see and feel the offered materials and fixtures in the real world before they made their final choice. 5 DISCUSSION AND CONCLUSIONS The use of product model technology in construction is still a subject for many research and development projects, (Fischer and Kam 2002, Ronneblad and Olofsson 2003, Jongeling et al. in prep). According to (Blokpoel 2003) the main strengths of the technology are in the areas of communication and configuration management. The main weakness is the lack of practical implementation where measured performances in terms of improved information flow and costs savings have been demonstrated. Even if many of the deficiencies in the information flow in today’s practice can be overcome by using product oriented IT support, the lack of product orientation, the fragmentised business process and lack of strong process owners in the construction industry are the main obstacles that have to be overcome before the technology is going to be spread. For the builder in the case study the main driving force has been the possibility to improve the customisation of the product and the manufacturing process. The builder is also a strong process owner. The case study also shows the importance of adapting the product information model to the actual building process and product structure. This is the main weakness of standardised product information models, such as IFC. If IFC is going to be the future standard in the construction industry, the product structure (the hierarchy of the model) must be configurable in order to map the hierarchy to different needs of the user. We are not convinced that this is the case to day. The use of MRP/ERP system for preproduction engineering, supply chain management and production control is widely spread in the manufacturing industry. In the building sector it is mainly used by suppliers of building components, (Bergstrom and Stehn 2004). The planning process in the construction industry is also focused on organisations and work breakdown, (Ballard et al 2001). Decision-making is often based

Process an information

393

on practice, general information and assumptions, resulting in sub-optimal solutions that often have a negative impact on the total project costs. The case study shows that product orientation and industrial building methods shift the focus from organisation and work breakdown to operations, flows and supply chain management. Concepts that are generally accepted as key performance indicators in lean production systems. A method for customer orientation in industrial construction that can be used to meet the varying demand on a market is mass customisation, (Krajewski & Ritzman 1999). According to Gu et al. (2002) the number of customised components and manufacturing operations can be balanced against the degree of customer satisfaction. The optimum is reached when the customers gets a product that fulfil the needs and expectations using a number of customized components and operations that still can be produced using the standardized manufacturing process. The interviews indicated that focus for customisation should be the options for the kitchen and bathroom. The possible options in the other rooms can be decreased or replaced by balancing the offer with a higher standard. The possibility of a shared customisation process with the real estate trustee in offering a more generous option program has several advantages: – The builder can have a more standardized production process and can focus only on options that refine or add-value to the end product, i.e. surface materials such as wall paper, tile and flooring. – The real estate trustee gets more involved in the customisation process. – Reducing the number of middlemen’s handling options would probably be beneficial for the end user. The interviews also showed that the surface finish and experienced quality of workmanship is of outmost importance. Therefore, the industrialised builders should focus to an equally high extent on the surface finish of the delivered product. Methods for quality assurance and control should be implemented to reduce complaints and increase the customer’s satisfaction. ACKNOWLEDGEMENT The financial support from SBUF—The development fund of the Swedish construction industry, Lindbacks bygg AB and the centre for information technology in construction (eBygg) at the Lulea University of Technology is greatly acknowledged. REFERENCES Agapiou, A., Clausen, L.E., Flanagan, R., Norman, G., Notman, D. 1998. The role of logistics in the materials flow control process. Construction Management and Economics 16:131–137. Al-Mashari, M., Al-Mudimigh, A., Zairi, M. 2003 Enterprise resource planning: A taxonomy of critical factors. European Journal ofOperational Research. 146:352–364. Avantra 2004. Avantra AB home page: http:// www.avantra.se, last visited 2004–06–05.

eWork and eBusisness in architecture, engineering and construction

394

Ballard, G., Koskela L., Howell, G., Zabelle, T. 2001, Production system design in construction. Proc 9th International Group for Lean Construction Conference, Singapore, 6–8 August 2001. 23–37. Bergstrom M. and Stehn L. 2004, Matching industrialised timber frame housing needs and enterprise resource planning—a change process, International journal of Production Economics, submitted. Blokpoel, S. 2003. Cooperation and Product Modelling Systems. Research Report 2003:17, Lulea University of Technology. Cassel-Engqvist, E. 2004. Kundorderstyrning i det industriella byggandet—Enfallstudie av volymbyggda trdhus, Master thesis (in Swedish), Lulea University of Technology. in press. Crowley, A., 1998. Construction as a manufacturing process: Lessons from the automotive industry, Computers and Structures 67:389–400. Enterprixe 2002. Enterprixe White Paper. Enterprixe Software Ltd. Helsinki, Finland. Fischer, M., Kam, C. 2002. Product models 4D, CIFE Technical Report Number 143, CIFE Stanford University, Stanford. Gann, M.D. 1996. Construction as a manufacturing process? Similarities and differences between industrialized housing and car production in Japan. Construction Management and Economics. 14:437–450. Gu, X.J., Qi, G.N., Yang, Z.X., Zheng, G.J. 2002. Research of the optimization methods for mass customization (MC). Journal of Materials Processing Technology, 129:507–512. Jongeling, R., Emborg, M., Olofsson, T. 2004, Shared product models for cast in place concrete, ITcon—Electronic Journal of Information Technology in Construction, Submitted. Naim, M., Barlow, J. 2003. An innovative supply chain strategy for customized housing, Construction Management and Economics 21, 593–602. Jongeling, R., Olofsson, T., Emborg, M. 2004. Towards virtual prototyping of construction innovations, Proc European Conference ofProduct and Process Modeling, ECPPM 2004, 8–9 September, Istanbul, Turkey. To be published. Krajewski, L.J. and Ritzman, L.P. 1999. Operation Management: strategy and analysis, fifth edition. USA: Addison-Westly Publishing Company. Olofsson, T., Cassel, E., Stehn, L., Ruuth, S., Edgar, J-O., Lindback, S. 2004. Produktmodeller i ettflexibelt industriellt byggande, Teknisk rapport 2004:06, Luled tekniska universitet (in Swedish). Pine II, B.J. (1993). Mass Customizing Products and Service. Planning Review, 22(4):6–13. Ronneblad, A., Olofsson, T. 2003. Application of IFC in design and production of precast concrete constructions, ITcon—Electronic Journal of Information Technology in Construction. http://www.itcon.org/2003/13. 8:167–180. SOU, 2000, Frdn byggsekt till byggsektor: Byggkostnadsdelegationens betdnkande. Statens offentliga utredningar 2000:44, Stockholm (in Swedish). Stehn, L. and Bergström, M. 2002. Integrated design and production of multi-storey timber frame houses—production effects caused by customer-oriented design, International Journal of Production Economics. 77:259–269. Stehn, L. and Jonsson, J. 1999. Conceptual and customer oriented development of a multi-storey timber frame house system. In proc. from IPCR-15, University of Limeric, Ireland, 9–12August 1999. 1199–1802. Tarn, J.M., Yen, D.C., Beaumont M., 2002, Exploring the rationales for ERP and SCM integration, Industrial Management & Data Systems 102(l):26–34. Ward, J. and Griffiths, P. 1996. Strategic planningfor information systems. 3rd edition, USA: Wiley Publisher. eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

RoadSim: an integrated simulation system for road construction management S.Castro & N.Dawood School of Science and Technology, University of Teesside, Middlesbrough, Cleveland, UK ABSTRACT: Road construction is an equipment-intensive process and its planning and performance management are essentially different from the methods usually adopted for other construction activities due to: the very high value of the road contracts; the very high cost of the inputs (equipment and materials); the physical extension of the works; the sensitiveness of the works to the meteorological factors; the environmental impacts and the potential conflicts with other social and economic activities. Current practices in the industry suggested that road construction is inefficient and projects are often over budget and over time. Also, project managers use only on their experiences, historical and technical data and gut feeling to manage the process. In order to have efficiency gains and construct projects on time and on budget, more innovative tools and techniques are needed to assist managers in planning and managing road construction projects. Also, there is a need for tools that will be able to assist project managers to study and compare all possible strategies and methodologies for the execution of the works and without comparison there is no evidence that the planner’s choice corresponds to the most advantageous possibility. To overcome that limitation and automate the road construction planning process a computer-based system has been developed, incorporating a knowledge base and a simulation of the principal road construction operations. The system is designated RoadSim and the respective framework is described in this paper. The main components of the systems are: knowledge based system that encapsulates rules; procedures, factors and technical data; central database for storing and retrieval project information; simulation engine and graphical user interface. The paper concluded that the adoption of RoadSim can help managers/planners to convert the strategy of the company into a planning, select the resources, define a construction budget, control productivity and use performance measurement indicators (cost and time) to redefine goals.

1 INTRODUCTION Current practices in the industry suggested that road construction is inefficient and projects are often over budget and over time (Castro, S 2002). Also, project managers use only on their experiences, historical and technical data and gut feeling to manage the process. In order to have efficiency gains and construct projects on time and on budget, more innovative tools and techniques are needed to assist managers in planning and

eWork and eBusisness in architecture, engineering and construction

396

managing road construction projects. Also, there is a need for tools that will be able to assist project managers to study and compare all possible strategies and methodologies for the execution of the works and without comparison there is no evidence that the planner’s choice corresponds to the most advantageous possibility. To overcome that limitation and automate the road construction planning process a computer-based system has been developed, incorporating a knowledge base and a simulation of the principal road construction operations. The system is designated RoadSim and the respective framework is described in this paper. The main components of the systems are: knowledge based system that encapsulates rules; procedures, factors and technical data; central database for storing and retrieval project information; simulation engine and graphical user interface. Due to the limitations on the size of the paper, only a brief description of current construction simulation literature is given. The ultimate purpose of all simulation systems is the determination and analysis of the behavior of a certain construction solution or a certain construction resource involved in a construction operation under different scenarios, measured basically by its physical feasibility and/or productivity. The simulation systems created by the research community—combined with visualization—revealed to be very helpful in designing complex construction operations and in making optimal decisions at the planning stage. Though the fact that there has been limited use of simulation in planning construction operations (Kamat and Martinez, 2001) in the past, it has been also recognized that the construction industry is progressively investing in the adoption of IT tools. Since the development of CYCLONE by D.W.Halpin in 1977, to simulate construction processes, a number of meaningful simulation systems have been created in order to achieve two important goals: to verification of the feasibility of a certain technical solution, either in terms of design and construction method or as a tool for the automation of planning in construction processes. Among the number of simulation systems developed by the research community for the construction industry, deserve especial mention INSIGHT (Paulson and Koo, 1987), MicroCYCLONE (Halpin, 1985), RESQUE (Chang, 1987), COOPS (Liu and loannou, 1992), DISCO (Huang et al, 1994), CIPROS (Odeh et al, 1992) and STROBOSCOPE (Martinez and loannou, 1994). AbouRizk and Mather (2000) developed a simulation system through integration with 3D CAD in which each resource is associated with its “atomic model”. The concept of “atomic model” has been presented by Ziegler (1987), Luna (1992) and Odeh (1992) in order to simplify simulation model building. One of the major conclusions that the authors have reached in reviewing historical and recent literature is that there is very little work that has been accomplished in the simulation of road construction. No paper was found dealing with road construction as a whole process composed by tasks defined as “plan the project”, “execute the works” and “evaluate the economic results”. The difficulty faced by the researchers is probably due to the fact that road construction has a particular culture for planning and performance management, brought to the construction process by: • The geographical extension of the works;

Roadsim: an integrated simulation system

397

• The sensibility of the road works to the local conditions (materials to be removed, water table, site organisation, accesses, etc.); • The sensibility of road works to the weather conditions; • The environmental impacts; • The potential conflicts with other social and economic activities. Specificity and simplicity seem to be the key for the success of simulation in construction. In the search of that simplicity and specificity, this paper presents a knowledge-based simulation system developed for the modeling of road construction operations and for the automation of the planning process in road construction projects. The simulation system is designated RoadSim and has been created to automate the process of: selection of resources; scheduling of the works and definition of contract construction cost. The next sections deal with the analysis of road constmction processes and specification of RoadSim. 2 ANALYSIS OF ROAD CONSTRUCTION PROCESSES The authors of this paper have been involved in road construction for long time (in particular Mr. Castro who is currently a production director at Mota, Lisbon) and this section is based on the analysis of current planning practices of more than 50 road construction projects. It can be concluded that every construction operation can be considered as a collection of integrated activities. Table 1 shows an example of road construction operations. This is not just a particular case in construction industry since it is common practice in construction modelling to break a complex system (construction operation) into subsystems (activity) of a lesser complexity. But in road construction it is not only a question of reducing complexity. Acting in that way we have the possibility to use the same simple model in a certain number of operations in which the activity is included. For example, in a cut-to-fill operation using motor scraper as a hauler it is possible to divide and model the whole operation into two sub-systems (activities): • The loading and hauling phase with the interaction between the track-type bulldozer and the motor scraper; • The levelling, watering and compaction phase, with the interaction of motor graders, water-tankers and rollers. The loading and hauling phases are exactly the same activity for other operations like “fill from borrow pit” or “cut to spoil” (mutatis mutandis) and therefore can be used in the modelling process of other activities (the same is valid for the levelling, watering and compaction activity). Using “activity” as a nuclear modelling element allows the possibility of analysis of the system in great detail, especially in terms of bunching effect, as shown in Table 2.

eWork and eBusisness in architecture, engineering and construction

398

Table 1. Example of road construction operations. System

Construction operation (fill from borrow pit, execution of base course, etc.)

Entity

Activity (dozing, hauling, compaction, etc.)

Attributes

Quantity, hauling distance, compaction degree, etc.

Resources

Equipment, materials, workers

The example shows that the simulation can be done by tracking continually certain variables (time elapsed, counter variables, state of the system at the time “t”, etc.). In our example, and assuming that the scrapers are loaded in a first-in, first-out manner (FIFO), the motor scrapers arrive at the loading point in accordance with a non-homogeneous poisson process and start immediately the loading operation if the pusher is free or wait in the queue if the pusher is busy. That is shown in the flow chart of Fig. 1. The example also shows that if the pusher (bulldozer) has to perform random tasks (ex: dozing and ripping every 250 m3), the consequent effect in the system can be studied (this is virtually impossible to execute using analytical models). Under the viewpoint of the road planner, the construction operation should be seen as a whole process. However, it is also noted that the duration and total cost of the overall operation is determined by one of the activities (leading activity). For example, in a cut to fill operation, the leading activity may be the “cut” if the other resources working for different activities in the operation have the capacity to haul, level, water and compact the totality of material produced in the cut activity. But may be the “hauling” activity if the haulers are not able to transport the totality of material produced by the cut activity and is inferior to the

Table 2. Identification of bunching effect and state of the entities (time points are different for bulldozer & motor scraper). Time point

Bulldozer

Motor scraper

Remarks

1

Position for pusher

Arrival to loading point

2

Start pushing

Start loading

3

Finish pushing

End loading

4

Travel backwards

Travel loaded

5

Position for pusher (completes cycle)

Start unloading

T5−T4=scraper travel loaded time

6

Finish unloading

T6−T5=scraper unloading time

7

Travel unloaded

8

Arrival at queue point

T3−T2=scraper loading time

T8−T6=scraper travel unloaded time

Roadsim: an integrated simulation system

9

399

Arrival to the loading T9−T8=scraper waiting time (bunching point (completes cycle) effect) T9/T5=number of scrapers in the operation

capacity installed at the filling point (levelling, watering and compaction). Consequently, the number, states and productivity of the resources present in a certain construction operation are affected and conditioned by the leading activity. If the selection of resources is correctly balanced, all resources will be working in the vicinity of their maximum possible productivity. If the team is unbalanced, some resources can experience important idleness and relatively high activity costs. Though it is important to identify the behaviour of each resource involved in the construction operation, in order to determine the compatibility among resources, define the different resource states (idle, active, etc.) and verify partial unit costs, the most relevant part of the modelling of a road construction operation is the identification of the leading activity in order to establish the real duration of the operation and, consequently, the cost.

eWork and eBusisness in architecture, engineering and construction

Figure 1. Motor scraper routine.

400

Roadsim: an integrated simulation system

401

3 THE CONCEPT OF ROADSIM It should be emphasised that the activities in a road construction process are the result of the action and interaction of resources. For a given road construction operation there are several or many possible combination of resources. The behaviour or final productivity of a certain combination of resources depends on: • Type of resources in the team; • Variable and specific factors such as “technical specifications”, “site organisation”, “operator’s skill”, “hauling distances”, etc.; • Random factors such as “weather”, “accuracy of geological information”, etc. Thus, the behavior of a given combination of resources for a certain construction operation can be modelled and simulated taking into account the characteristics of the resources involved and their interactions being the simulation result made dependent on the variable and random factors. For that, and using practical knowledge, RoadSim established the rules governing the action of a resource in a given process by considering two main aspects: • The inherent characteristics of the resources (power, bucket capacity, etc. for equipment; size, chemical composition, etc. for materials; skill for labour); • Interaction with other resources and constraints present in the same operation. The study and correspondent simulation modelling of the behaviour of resources in construction operations needs the identification of the tasks usually performed in road projects. For that, and as part of the establishment of RoadSim, a data collection process (Castro, 2002) has been undertaken in several countries representing different levels of economic development and different geographical conditions and referring to projects executed in the period 1996–2001. For road works, that is, “earthworks”, “drainage” and “pavement” (bridges were not included in the research at this stage), 50 tasks or construction operations have been identified as forming part of the BOQ of road contracts. These 50 tasks form part of the RoadSim menu. For every task or construction operation identified it has been defined a number of possible resource combinations and possible construction methods, leading each combination to different costs and time of execution. Different type of resources means the use of a totally different kind of resource (ex: hauling of soils using a motor scraper or a tipper truck). Therefore, the power, model or size of the resource only changes the performance but neither the type of resource nor the way the work is carried out. For the modelling of the action of the resources involved in the execution of the tasks identified as forming part of the RoadSim standard BOQ, a relation between the input (cost and time) corresponding to the resource allocated in the task and the resulting output (m3, m2 or ton of work done), that is, the productivity of the resource in the task was determined. The same was done for the possible resource combinations and respective interactions. Corrective factors have been established to take into account: • operator’s skill

eWork and eBusisness in architecture, engineering and construction

402

• site organisation • total duration of the activity (long duration increases productivity) • duration of the cycle time (short cycle times are more susceptible of experiencing losses in productivity) • bunching effect • random works.

4 STRUCTURE AND SPECIFICATION OF ROADSIM Figure 2 shows a road construction project, which is composed of three, tasks or phases: the planning

Figure 2. Inputs and actions in road construction. process, the execution of the works and the evaluation of the economic results phase. These three phases can be considered as the actions responding to the inputs represented by a road project. RoadSim architecture has been designed in order to make the current project elements (nature and quantity of works to be carried out, technical specifications, site constraints, etc.) available as input for the simulation modelling programme which, in reaction, returns actions such as “selection of resources”, “scheduling of works” or “construction cost estimating”. Figure 3 shows the component system of Roadsim. As can be seen, the RoadSim structure is composed by three principal elements: database, knowledge base and simulator. The system was developed using integrated Access database, MSproject, AutoCAD, Excel Spreadsheets and VBA application to improve and automate fimctionalities of the different software. The following sections outline the three components in details.

Roadsim: an integrated simulation system

403

5 DATA AND KNOWLEDGE BASE The RoadSim data and knowledge base contains three important elements. The first is the collection of the work packages of every routine operation as indicated in the previous sections. As the works can be performed using different equipment combinations, the database is constructed in order to define all routine operations and their alternatives in terms of equipment combinations.

Figure 3. RoadSim components.

eWork and eBusisness in architecture, engineering and construction

404

Figure 4. Visualisation of earthworks progress. The second element is the productivity formulas of the equipment combinations. Different combinations lead to different productivities that can be estimated with a certain mathematical formula, which is the function of its work conditions and equipment properties. These productivity formulas are the result of historical work performances of the referred to equipment combination. This is regarded as the knowledge base part of the system. The third and last element of the database contains the unit costs of the resources (equipment, materials and labour). As road construction is equipment-intensive process, special care has been granted to equipment costs, namely by considering: • Life time of the equipment unit as the average of at least three working conditions. A guide line is provided in RoadSim to allow the user to make the correct choice of the depreciation period which should be based on usefiil life time rather than write-off life; • The formula of the hourly owning and operating cost allows the user to customise the calculations.

6 SIMULATOR The simulator is conceived to unambiguously describe, both spatial and temporally, a complex road construction operation, depicting the movements, transformations and interactions between the resources involved. The simulator receives the information referring to a new road contract (BOQ, technical specifications, contract agreement, working conditions, etc.) as input and then retrieves the relevant data in the database to perform a set of programming calculations. The simulator recognises the operations from the inputs and automatically generates all possible options of equipment combinations for the operations. After the planner inputs

Roadsim: an integrated simulation system

405

more details of every operation, the arithmetic module produce results of estimated productivities and required execution durations. For every option, the simulator estimates the respective cost of execution using the information stored in the database. After the execution of the works on site, the planner can later introduce the actual productivity of work done in an up dating module to enable RoadSim to check the difference from the estimation and readjust the existing formula, if necessary. In terms of earthworks, RoadSim allows the visualisation of how the road evolves with time, as shown in Figure 4. This RoadSim feature uses Integration with CAD, since it is common practice today to produce road designs using CAD. Obviously, the visualisation refers to a pre-selected section of the road. Using this application, the planner can select the period of time he wishes to analyse and the unit of counting (day, week or month). 7 VALIDATION This is a brief section about the validation of the system and more information will give in a subsequent paper. RoadSim system has been tested in the re-planning of the highway A25—“Talhadas-Vouzela” section (Portugal). The A25 is a 166 km long highway spanning from the port city of Aveiro (Portugal) to the Spanish border of Vilar Formoso. The highway will replace the existing IP5. The section “Talhadas-Vouzela” has a length of 17.1 km, a cross section of 2X2 lanes with a total with of 28 m. The works in this section are basically the widening of the existing IP5. The main quantities of work include 2 000 000 m3 of excavation (650000m3 in rock), 400000ton of stone base and ISOOOOton of asphalt. The works in this section started in June 2003. Meaningful differences in terms of geological data and hauling distances, more severe environmental restrictions than expected and a more accurate safety assessment led to the need of a replanning process. The re-planning work was done using both the traditional method and the RoadSim. Simulation output from RoadSim was compared with the actual system installed in the project (equipment combinations and performances), with the following conclusions: • The re-planning process took only 2 days, instead of the 15 days using traditional methods; • The results from RoadSim are too close from the results obtained using traditional methods; • RoadSim was able to give the output of all possible options, while the traditional method only focused in the actual combination of equipment. The tests already done indicated that the system could be used to select the resources, schedule the works and estimate the construction cost of road contracts. However, more tests are to be performed to evaluate the applicability of RoadSim and fiirther analysis and refinements are needed to validate the system.

eWork and eBusisness in architecture, engineering and construction

406

8 CONCLUSIONS Current practices in the industry suggested that road construction is inefficient and projects are often over budget and over time. Also, project managers use only on their experiences, historical and technical data and gut feeling to manage the process. The paper concluded that there is a need for tools that will be able to assist project managers to study and compare all possible strategies and methodologies for the execution of the works and without comparison there is no evidence that the planner’s choice corresponds to the most advantageous possibility. The paper presented a computer-based system has been developed, incorporating a knowledge base and a simulation of the principal road construction operations. The system is designated RoadSim and the respective framework is described in this paper. The paper concluded that the model is important to road construction planning and has the potential to save cost and improve efficiency. RoadSim will provide a platform for road construction automation in the construction industry. ACKNOWLEDGMENT The authors would like to acknowledge the efforts of Mr. V Benjaoran for the development of the software. REFERENCES AbouRizk, S. and Mather, K. (2000). “Simplifying simulation modelling through integration with 3D CAD”. J. Constr. Engrg. And Mgmt, ASCE 126(6) pp. 475–483. Castro, S. (2002). “Integrated simulation models applied to road construction management: a conceptual framework”. Internal report, University of Teesside. Castro, S. (2002). “Analysis of road construction process aiming the creation of an automated management process”. Internal report, University of Teesside. Chang, D.Y. (1986). “RESQUE: a resource based simulation for construction process planning”. PhD dissertation, University of Michigan. Halpin, D.W. (1977). “An investigation of the use of simulation networks for modelling construction operations”. PhD Thesis, University of Illinois. Huang, R., Grigoriadis, A.M. and Halpin, D.W. (1994). “Simulation of cable-stayed bridges using DISCO”. Proc. 1994 Winter Simulation Conf. 1130–1196. Kim, K.J. and Gibson, Edward Jr. (2003). “Interactive simulation modelling for heavy construction operations”. Automation in Construction, 12(1) pp. 97–109. Law, Averill, M. and Kelton, W.D. (2000). “Simulation modelling and analysis”. 3rd edition, McGraw-Hill. Ledin, Jim. (2001). “Simulation Engineering”. CMP books. Liu, L.Y. and loannou, P.G. (1992). “Graphical object-oriented discrete-event simulation system”. Proc. 1992 Winter Simulation Conf. 1285–1291. Llunch, J. and Halpin, D.W. (1982). “Construction operations and microcomputers”. J. Constr. Div., ASCE 108(1), pp. 129–145.

Roadsim: an integrated simulation system

407

Luna, J.J. (1992). “Hierarchical modular concepts applied to an object-oriented simulation model development environment”. Proc. 1992 Winter Simulation Conf. 694–699. Martinez, J.C. and loannou, G.P. (1994). “General purpose simulation with stroboscope”. Proc. 1994 Winter Simulation Conf., 1159–1166. Odeh, A.M. (1992). “CIPROS: Knowledge-based construction integrated project and process planning simulation system”. PhD dissertation, University of Michigan. Paulson, B.C.Jr. and Koo, C.C. (1987). “Construction operations simulation by microcomputer”. J. Constr. Engrg. And Mgmt., ASCE, 113(2), pp. 302–314. Peyret, F., Jurasz, J., Carrel, A., Zekri, E. and Gorham, B. (2000). The computer integrated road construction project. Automation in Construction., 9, pp. 447–461. Ziegler, B.P. (1987). “Hierarchical modular discrete-event modelling in an object-oriented environment”. Simulation, 49(5), 219–230.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Connet Turkey—gateway to construction in Europe A.Dikbaş Istanbul Technical University, Project Management Center, Istanbul, Turkey S.Durusoy DNA Internet Solutions Inc., Istanbul, Turkey H.Yaman, L.Tanaçan & E.Taş Istanbul Technical University, Faculty ofArchitecture, Istanbul, Turkey ABSTRACT: For the construction industries to move into the knowledge society and knowledge economy they need to be able to build upon their existing information base. Drawing together the information resources within nations and connecting them with each other to form transnational resources enables a more effective, informed, and intelligent industry. ConNet is such a solution developed among participating countries which are Belgium, Finland, Germany, Iceland, Italy, the Netherlands, Slovenia, Spain, the United Kingdom and Turkey. Turkey has developed the Turkish gateway to gain throughput in efficiency for the construction industry and also designed and implemented necessary tools and software for providing relevant, timely, and up-to-date information, trade and ebusiness services through a web portal.

1 INTRODUCTION 1.1 Connet Europe Connet Europe consists of a set of electronic information services offered through one or more web portals and accessed through the European Gateway. Connet Europe plays the role of the integration point where each country site is registered with its online services (Bloomfield et al. 2001a & 2001b). Such integration point not only provides a visual portal environment, but also information exchange utility where local information databases are shared for multinational reach of knowledge. It is also a vital role of this gateway to provide translation services to discard language differences as an issue in knowledge sharing. The Connet Europe gateway brings together the dispersed knowledge to better utilize information in a multinational business environment where industry players in each participating country already carry out projects across each other. Each national service is not necessarily provided by one vendor; in fact may be a set of services from varying sources, again brought together through each national gateway.

Connet turkey—gateway to construction in Europe

409

It is not a strict must that each country provides the same set of services and information. As can be seen on the European Gateway; some countries provide certain types of services whereas some provide others, seamlessly integrated to work together efficiently. 1.2 Connet Turkey Connet Turkey has started as a research and development project at Istanbul Technical University Project Management Center (ITU-PMC) and is currently being

Figure 1. Schematics of information exchange. finalized by ITU-PMC and DNA Internet Solutions Inc. (DNA) towards a goal to commercialize the portal and services. Connet Turkey covers the full range of information, consultancy, training, trade and ebusiness services. Construction industry in Turkey is merely introduced to portal services and there is a growing demand for a trusted party to develop and operate a large scale portal. ITU-PMC and DNA collaboratively provide the necessary resources, know-how and initial information to develop and launch Connet Turkey portal bearing a content management infrastructure with repository management, page layout management and site map management in the first phase. This first phase content management infrastructure provides necessary tools to manage information, consultancy and training services.

eWork and eBusisness in architecture, engineering and construction

410

The second phase is to provide specialized services like building materials classification system, trade system, download center and banner advertisement management. Final phase of the project is the implementation of subscription services management infrastructure, allowing rapid commercialization of the whole system, bringing together various information providers and information seekers, namely the players in Turkish construction industry. Finally, Connet Turkey is also a very important tool and means for Turkey integrating with the European Union (EU). By literally integrating one of the largest industries in Turkey with EU, a working model for such deed will eventually have accomplished, practically implemented and tested. 2 PROJECT OVERVIEW 2.1 Key problems andproject goals The construction industry occupies the largest share among the overall economy. 11% of total gross national income among EU is generated by the construction industry. With an estimated number of 8.8 million employees—which is 7% among all—it is also an important market itself for many other industries. On the contrary, the construction industry remains at the end of the list for information technology penetration with a large gap to its closest competitors. In order to gain the necessary competitive advantage and increase efficiency, both large players and SME’s must define information technology demands. ITUPMC with its well possessed knowhow and experience, is equipped with the necessary information and skills to define the demands and provide the supply, namely Connet Turkey. Connet Turkey web portal is targeting to fulfill many of the industry’s expectations to meet: – SME requirements, – easily serve geographically disparate subscribers and, – well-organized information accompanied by bestpractices and case studies. The portal services target to solve common issues that are known as: – Standardization, – Improved communication, – Time and location independent collaboration, – Improved knowledge exchange, and if solved, known to gain important increase in productivity and efficiency. To address all issues, ITU-PMC and DNA collated a list of services to be launched on Connet Turkey web portal: – Management and information system for construction projects, – Technical information repository, – Software and hardware inventory,

Connet turkey—gateway to construction in Europe

411

– News central, – enter for consultancy services, – Classification systems center, – Web hosting services, – Online B2B building materials market, – Banner and ad server, – Waste material and idle equipment utilization market, – Center of continuous education, – Construction management service. Outputs of a research project carried out in Faculty of Architecture at Istanbul Technical University (ITU) will be used in classification system and online B2B building materials services of the Connet Turkey project. Main objectives of the “Building Materials Information System” (BMIS) project were to examine Turkish market and to develop an web-based information system in the context of building materials and components (Tas et al. 2002). Outputs and data structures of the BMIS project are being revised for Connet Turkey project compatibility. 2.2 Management and information system for construction projects This web based tool is developed for managers and project responsible. It allows multiple construction projects to be managed—budget-wise and time-wise-through cost analysis, project schedule, building material and work standardization. This tool is especially helpful for universities, municipalities and other government organizations who seek to manage their construction projects. 2.3 Technical information repository This repository and portal gateway is planned to be the one stop access point to all written and published work available to the construction industry and covers all disciplines. The service allows content providers to integrate their content into the Connet Turkey web portal. 2.4 Software and hardware inventory This inventory module provides means of categorization and access to all available hardware and software information technology tools and products for the benefit of the construction industry. Designers at the site or office can gain instant access to this module to find required hardware and software. 2.5 News central The news central is going to be a spot where all information will be gathered from news service providers and centrally published to subscribers. News headlines and content is

eWork and eBusisness in architecture, engineering and construction

412

grouped, for convenience, into categories such as government projects, upcoming bids, projects news, and technology news and such. 2.6 Centerfor consultancy services This service will cover all consultancy needs, especially contract management, project analysis, contract analysis, arbitration and general consultancy as well as research and development support. 2.7 Classiflcation systems center Turkish building materials industry bears a large number of suppliers, yet lack a consistent standardization and classification. This very module is especially important for the integration process with the EU and supply all necessary materials cataloging requirements. Suppliers and their products will also be displayed under categories. 2.8 Web hosting services SME’s in Turkey merely have the necessary abilities and budget to start corporate web sites, let alone e-business sites. A web manageable hosting services is going to be provided through a centralized data center infrastructure. 2.9 Online B2B materials market In order to enlarge the reach of building material suppliers in global markets, as well as the national market, an on-line trade platform is planned to be developed and operated. 2.10 Banner and ad server The portal is going to utilize banner ads both accompanying its own income model, and assisting subscribers and banner ad clients for better market penetration and brand communication. 2.11 Waste material and idle equipment utilization market Reusable second hand machinery and waste materials/ equipment is a very important asset if utilized. Through this module, such assets will re-enter the market, thus maximizing efficiency and decreasing certain project costs for portal subscribers. 2.12 Center of continuous education ITU-PMC is already a well established continuous education provider in Turkey. This module is going to allow a wide spread reach of such educative content through elearning.

Connet turkey—gateway to construction in Europe

413

2.13 Construction management service General information, links and services will be offered through this section of the portal. 3 TECHNICAL INFRASTRUCTURE 3.1 Connet integration infrastructure The whole system is based on standardized platform independent and scalable technologies such as Java and XML.

Figure 2. Connet integration map. After each country develops its own portal interface and integration with local content and news service providers, all local database content is to be reachable through other countries. To provide such means, XML integration technology and common techniques are to be used. Integration gateway programs are to provide inter-portal communications and information exchange while Connet Europe Gateway is to utilize add-on services such as the translation engine.

eWork and eBusisness in architecture, engineering and construction

414

3.2 Connet Turkey infrastructure Parallel to the international infrastructure components, Connet Turkey web portal utilizes Java and XML technologies. The core of the system is designed and implemented on already preferred open-source server infrastructure such as Apache Jakarta Tomcat JSP engine/ servlet container and MySQL relational database management system. The whole system is based on open technologies and the operating system choice is similarly Linux for its low cost, robust and secure environment. The heart of the portal is its content management system with centralized typeindependent content repository, layout management and site navigation management solution allowing the right, up-to-date and consistent information to be displayed on the web site. 4 PROJECT STAGES AND INCOME 4.1 Project stages The project has past and is following phases until its ultimate goal of successful implementation and commercial income model, these stages are: – Information gathering and analysis, – Design and construction, – Dataentry, – Connet integration, – Complete localization, and – Commercialization. 4.2 Project income and goals It is very obvious and eagerly awaited that this project is going to play critical role for the improvement and EU integration of the Turkish construction industry. All players in the industry are welcomed and targeted to be subscribed to at least one or more of the services offered. Enabling single point of information aggregation, easier access to information and development of shared knowledge is aspired. Especially SME’s as well as the large players will more easily find business partners for international projects, and provide standardized goods and services on a multinational scale. – For the first time, e-business enabling the construction industry. – Exploring new business opportunities under the EU identity and umbrella. – EU standards being implemented on a live project in international scale.

5 CONCLUSION

Connet turkey—gateway to construction in Europe

415

Turkish construction industry, unlike the structure in other Connet partnering countries and though large and promising, is at an early stage in terms of information and knowledge sharing and management. Thus, Connet is a well crafted opportunity for the players especially SME’s—in Turkey to obtain higher effectiveness and innovation, standards based design and production through information-reach, collaboration, training and consultancy. Connet is believed to be an important tool to reach at an international business stage of competition through collaboration. REFERENCES & ACKNOWLEDGEMENTS Bloomfield, D., Amor, R., (2001a), “I-SEEK: An Internet gateway to European Construction Resources”, Proceedings of the CIB W78 conference, Mpumalanga South Africa, May 30-Jun 1. Bloomfield, D., Amor, R. and Groosman, M., (2001b), “The Evolving CONNET Gateway to European Construction resources”, Proceedings of the CIB W102 conference, Melbourne, Australia, 26–27 March. Connet project web site http://www.connet.org/ (2004). Tas, E., Tanacan, L., Yaman, H., (2002) “Design of a Building Materials Information System for Turkey”, Unpublished Research Found Project Report, Istanbul Technical University.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.)

eWork and eBusisness in architecture, engineering and construction

416

© 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Modelling collaborative processes for Virtual Organisations in the building industry M.Keller, P.Katranuschkov & K.Menzel Institute of Construction Informcttics, TU Dresden, Germany ABSTRACT: The paper describes how collaborative business processes can be enhanced, harmonised, eventually standardised and re-used with the help of formalised business process patterns for initialising and operating construction projects. A methodology is introduced that structures aspects of construction projects by defining different classification types for the overall project such as geometrical and semantic description of construction objects as well as fimctional and organisational aspects. The use of an extensible reference process library identifying—generically—communicating actors, information requirements, communication requirements, applicable standards, meta data types etc. is shown, and the added value that can be achieved by combining organisational and technical Virtual Organisation aspects in an extensible, re-usable specification of collaboration processes for Virtual Organisations is explained.

1 INTRODUCTION Recently, considerable research efforts have been spent on the modelling of Virtual Organisations (VO) and the related processes, phases, topologies, and coordination/ collaboration aspects. However, the developed models have different background, take different viewpoints, and apply different specification approaches. A common weakness is the lack of appropriate formal methods, consistent modelling paradigms and adequate modelling tools. Therefore, it is necessary to consolidate and synthesise the gained insights and develop a formal methodology for harmonised process modelling. Especially efforts for the development of domainspecific requirements and inter-enterprise process modelling paradigms are of utmost importance. The main objective of the research presented in this paper is the development of a systematic approach for the specification, instantiation and management ofprocess pattern related to the collaboration and the information exchange between the different types of enterprises that may form a VO in the building industry. The application of process modelling paradigms can foster efficient interorganisational business relationships and help to achieve a common understanding for project management and information exchange. However, on each specific construction project various aspects need to be adapted to the particular restrictions of the domain such as: legal regulations, functional and organisational structures, and technical aspects.

eWork and eBusisness in architecture, engineering and construction

418

To define these requirements for VOs in the construction sector an analysis of existing regulations, common procedures, and research results has been conducted by the authors. On the basis of that analysis an overall modelling framework is suggested for modelling and instantiating collaborative processes for Virtual Organisations in the building industry. Moreover, an extensible reference library of tasks identifying organisation and communication requirements as well as standards and meta data types will be introduced. The added value that can be achieved by combining organisational and technical VO aspects will be explained. The following chapter will first of all introduce the requirements of VOs in the building domain. 2 VIRTUAL ORGANISATIONS IN THE BUILDING INDUSTRY Construction projects are characterised by a high complexity of problems. They usually involve a great number of different specialists such as architects, structural engineers, building services engineers, quantity surveyors, cost estimators, etc. Furthermore, the different business goals and perspectives of the participating partners regularly result in opposing project interests and conflicts in the design and construction phase. Applying the principles of Virtual Organisations for construction projects these problems may be reduced by establishing a common understanding for the business operation within the consortium. 2.1 Deflnition of Virtual Organisations A Virtual Organisation (VO) is a cooperation of legally independent enterprises, bodies and/or individuals, which perform businesses on a common understanding (Mertens et al., 1998). The business associates in a VO primarily participate with their core competencies. To external partners the VO acts as a single company. According to Picot et al. (2001) the use of modern information and communication technology enables the creation and operation of VOs by: – penetrating regional and international borders – an improved integration of third parties communication systems – the extension of capacity limits by the incorporation of third parties – worldwide access to knowledge carrier and knowledge bases – cross-linking processes and actors Thus, the aim of the Virtual Organisation is to gather various competencies of different companies in order to enhance efficiency and productivity while decreasing overheads. 2.2 Virtual Organisation phases The lifecycle of a VO can be broken down into five or six phases as indicated in Figure 1. Due to the dynamics of a building project several of these phases may run simultaneously. While one partner is already leaving the project, another partner is still negotiating with the project manager. Every phase can be supported by an information and communication system, whereas some systems might be comprehensive.

Modelling collaborative processes for virtual organisations

419

2.3 Construction speciflc aspects of VOs Virtual Organisations can be characterised by different parameters such as: duration, topology, participation, co-ordination, and visibility (Camarinha-Matos et al., 1999). According to this classification a construction project is mostly structured as indicated in Table 1 (construction project specific are checked). Considering the specification of VOs a construction project has a star like architecture coordinated by the project manager and the architect respectively. Domain specialist like construction engineers, earthquake engineers, etc. will support him. The domain manager, who in turn is supported by various engineers, will act as a representative of the virtual company.

Figure 1. Lifecycle of a Virtual Organisation. Table 1. Classification of a construction project (Keller et al., 2003). Duration

Participation

□ Single Business

□ Single Alliance

Long Term Alliance Topolgy: Variable/Dynamic Nature □ Fixed Structure Coordination Star-Like Struture □ Demoratic Alliance □ Federation

Mulitple Allinace Visibility: □ Single Level Multi Level

eWork and eBusisness in architecture, engineering and construction

420

Due to the dynamic construction design process it is almost inevitable to individually connect and disconnect companies over the project. Therefore, the main project information need to be accessible to each VO-member. New members must be capable to easily gather all relevant information together with the status of the project and its boundary conditions. Therefore, data exchange standards as well as communication methods should be aligned to the activities in order to reduce information losses and lacks of communication. 2.4 Collaborative process support for VOs The information and communication exchange—in particular the management of workflows—for the collaborative processes in operation phase of construction VOs is still insufficiently supported. Particularly with regard to inter-organisational business processes modelling paradigms are missing. The application of process modelling paradigms can foster efficient inter-organisational business relationships and help to achieve a common understanding for project management and information exchange. However, for each specific construction project different aspects need to be adapted to the particular restrictions of domain such as: (1) legal regulations, (2) functional and organisational structures and (3) technical aspects. In the following chapters we propose a methodology how construction projects can be structured by different classification types to facilitate inter-organisational business processes modelling. 3 PROCESS CONTEXT AND SCHEMES FOR CONSTRUCTION PROJECTS In current practice, dedicated data models are successfully employed and integrated for the processing of various business tasks but this is not being done in a harmonised manner, on the basis of a consistent process-centred approach. Efficient modelling of collaboration processes within a VO should encompass both tasks, subtasks, their dependencies and the actors performing them. The necessary data type specifications, and managerial information about who is exchanging what data with whom and what kind of (standardised) representations should be used for that purpose. For the definition and instantiation of specific construction processes it is essential to define the context, which influences the realisation of a certain construction tasks. That means all parameters influencing the realisation and management of process need to be specified in advance. Therefore, it has to be analysed which factors influence the realisation of a construction project. This comprises geometrical information and semantic description of the construction objects as well as functional and organisational aspects. This chapter will introduce and classify the different parameters influencing the instantiation and management of construction projects. Firstly a decomposition of the complex construction processes into project-parts will be conducted by specifying different classification types for the overall project. Secondly, the definition of

Modelling collaborative processes for virtual organisations

421

construction specific workflow schemes supporting communication as well as information exchange aspects for VOs will be introduced. 3.1 Classification types of construction projects Construction projects are defined as complex one of a kind projects. Thus, the major concern of the project manager is to reduce this complexity by subdividing it into integral/coherent sub-projects or activities to be merge again after completion. The major interest of all project participants is in an effective and efficient planning, realisation and control of the project considering the three main project risk-factors: – cost – time – performance

Table 2. Classification types for the boundary conditions of construction projects.

In order to quantify these risk-factors using distinct values (for workflow processes the limitation of time is of uttermost interest) it is essential to define the influence factors and respectively the context that controls them. Therefore, the entire project will be decomposed into its elements and structured in a hierarchical manner. The aim is to formulate a project workflow or schedule, in which each single work-task is determined by a specific outcome. The work-tasks and the corresponding outcome have to be adjusted to the boundary conditions of the project The boundary conditions of the work-tasks can be classified in regard to various criteria, that can again be organised according to two the main classification types specifying the (a) Project-Type Organisation and the (b) Project Structural-Scheme. These types in turn consist of two sub-types as indicated in Table 2. The major difference between the Project-Type Organisation and the Project Structural-Scheme is that the former is defined by the project manager or the building owner in a very early state of the project. It is also influenced by legal guidelines and

eWork and eBusisness in architecture, engineering and construction

422

informal recommendations. Modifications within the Project-Type Organisation at project runtime are very limited. Therefore, this classification type is considered as static or external influence parameter. In contrast to this, the Project-Structural-Plan will be instantiated and refined at project runtime. With the progressing of the project the quality of the information available on the objects of the Project-Structural-Plan is improving. Thus, this classification type is characterised by dynamic or internal influence parameters. Figure 2 indicates the relationships between the project risk-factors and the described classification types for construction projects. In the following chapters the classification types and sub-types will be described in more detail providing corresponding examples. 3.1.1 Project-Type Organisation The Project-Type Organisation determines the boundary conditions for the Project Organisation Structure

Figure 2. Construction project management scheme (Branden-berger et al., 1996). and the Structuring of Operations. It is set up by the project manager or the building owner, considering legal and organisational aspects as well as best practise experiences.

Modelling collaborative processes for virtual organisations

423

Project Organisation Structure The requirements on the Project Organisation Structure within construction projects are considerable, since the realisation of such a project passes through several different requirements within each phase. Thus, the Project Organisation Structure has to be aligned to all phases. Furthermore, every construction project will have its own Project Organisation Structure. In practice different Project Organisation Structures are realised, such as: – Conventional/classical organisation – Bidding consortium and joint venture – General planner – General contractor The predefinition of the organisational arrangement within the different phases of the project mainly depends on the building owner. Depending on the organisational structure his influence and involvement in the project varies. Structuring of Operations The overall construction process can be subdivided into phases of thebuilding lifecycle: initiation, planning, realisation, operation/usage and closure/destruction. The Structuring of Operations provides the guidelines for the sequences of tasks, responsibilities, coordination procedures, office organisation, etc. within the individual phases. Different national as well as international regulations and recommendations exist, which standardize the procedures within construction projects. For example in Germany the HOAI1 standardizes the tasks and responsibilities of architects and engineers in construction projects. The HOAI is phase oriented and catalogues the activities that have to be performed by designers and engineers in cooperation with other participants of the project, like craftsman and construction companies. An international approach for structuring the construction processes is provided by the Generic Process Protocol. It considers that the lifecycle of a project development is described in terms of four main stages, i.e. pre-project stage, pre-construction stage, construction stage and post-completion stage, with 11 associated sub-stages (phases). 3.1.2 Project Structural-Scheme The Project Structural-Scheme hierarchically organises the entire project in sub-projects or -tasks. This structure can be both object orientated (e.g. by construction components) and function orientated (e.g. by work-packages). In praxis combinations of the object oriented and function oriented project views are common, since a single structure lead to understandings (Greiner et al., 2000). By preparing a Project Structural-Scheme it is possible to generate a reasonable time schedule for the different tasks of a project within general steps: 1. The Project Structural-Scheme will divide the entire project into different workpackages. 2. Each work-package will have is own workflow defining the different tasks to be performed.

eWork and eBusisness in architecture, engineering and construction

424

3. From the workflow a time-schedule can be derived by applying the project specifics Function Orientated Project Structural-Scheme The focus of the Function Orientated Project Structural-Scheme is on the performance of tasks. That means that the overall project will be divided into its different activity-types. Each activity-types will be performed by an actor of the VO. Another option to structure a project by its function is by dividing it into its various phases that will be performed during the project. An example of a Function Orientated Project Structural-Scheme is given in Figure 3. A sound example to structure a project in a functional manner is provided by the German STLB2. 1

HOAI—“Honorarordnung ftir Architekten und Ingenieure”, regulation to calculate the hires for performed work of architects and engineers. The HOAI structures the construction design and realisation process into nine phases. 2 STLB: The “Standardleistungsbuch” (Standard Construction Service Manual) is a general, standardised catalogues of text modules for the specification of construction activities.

Figure 3. Example of a Function Orientated Project Structural-Scheme.

Modelling collaborative processes for virtual organisations

425

Figure 4. Example of a Object Oriented Project Structural-Scheme. Object oriented Project Structural-Scheme With the Object Oriented Project Structural-Scheme the entire building will be divided into its building components. This structuring can be performed by two different focuses: 1. Spatial focus (e.g. house → floor → room) 2. Domain focus (see Figure 4) One possibility to set up an Object Oriented Project Structural-Scheme is given by the DIN 2763 “Building Costs”. The ifc2x building model also provides an object orientated structuring of a construction design. 3.2 Process patterns In general a workflow modelling methodology comprises three general phases: 1. Definition of a workflow language (or model) to specify the legal expressions in a formal manner. 2. Development of a generic representation of a workflow using the workflow language.

eWork and eBusisness in architecture, engineering and construction

426

3. Implementation and instantiation of the business processes applying the required workflow for the specific workflow management system. To set up the processes of a construction project various workflows have to be modelled for each work-task by the members of the VO. Since, several similar tasks have to be performed in one project or even within different projects the definition of generalised, reusable workflow-patterns is beneficial. The following section will give an example of a workflow-library developed for construction project specific requirements (from Katranuschkov et al., 2004). The Process Matrix mainly developed within the EU ICCI project describes a new process-centred method for capturing business and user requirements as well as their inter-linking with applicable ICT standards. The essence of the developed method is in recognising requirements and use-cases in the context of the real construction process, identifying the actors and roles for each individual activity and associating these activities with information, communication and standardisation requirements on the basis of a formalised specification. The Process Matrix rationalizes many existing models bringing them into a coherent framework. Its essence is in combining and further extending aspects of the Generic Process Protocol (Kagiouglou et al., 1998) to achieve a harmonized, commonly applicable identification of processes and related requirements. The Process Matrix is the result of critically reviewing and merging the content of nearly 100 process models to define a simple formal method for identifying atomic process concepts that should be universally applicable. From the end user viewpoint the Process Matrix appears as a simple table that brings all stored information concerning a reference process together in 3

The DIN 267 is used for the determination and classification of costs in building construction. It acquires the costs for production, reconstruction and modernisation tasks including the association expenses.

Figure 5. The structure of the Process Matrix. one line. This approach has been adopted because experience shows that industry end users are not particularly familiar with formal modelling notations.

Modelling collaborative processes for virtual organisations

427

Each row in the matrix represents a single business process and the information communication shows the end result and who is supposed to use that result in subsequent processes. Each process can be broken down further into sub-processes or detailed by using a diagramming approach such as UML activity diagrams. Processes are explicitly represented in the matrix by their Process_ID, Name and optional Description. They are defined as being either actions or activities. The definition of action and activity is adapted from their specification in UML. Processes are organised by project stage whereby the organisation of project stages set down in the Generic Process Protocol is used with some extensions. A process has a typical formalization of communication indicated in the matrix, e.g. 3D model, 2D drawing, cost plan, schedule, list etc. This is covered by the attribute basic information type. Information in a process is received from one or more predecessors (as a prerequisite for executing the process), created and exchanged within the process, and passed over to subsequent processes. Two major extensions have been defined to complement the basic Process Matrix. Their purpose is to provide additional details on the requirements to a process that can be seamlessly incorporated in the matrix. These aspects are the generic information type (related to some classification system) and the speciflc information type (enabling association of information items to secondary, more detailed classification items). Information Requirements Extension The objective of this extension is to identify the actual data communicated in a process that can serve as guideline for the definition of more specific requirements for a software system or tool intended to support that process. In addition to the basic, generic and specific information types it introduces two new fields: data model and data content. Communication Requirements Extension The objective of this extension is to identify the ‘technical’ aspects of the communication between the actors in the process, such as the model of the communication process (e.g. client/server), the network protocol (e.g. FTP or HTTP), the exchange/messaging format used (e.g. XML, HTML, IFC exchange file) etc. It can also capture requirements for more advanced communication techniques such as SOAP or WSDL. The components are structured in three groups: communication model, communication protocol and exchange format. 4 PROCESSES MODELING APPROACH The aim of this paper is to introduce an approach for collaborative business processes modelling, in order to enhance, harmonise and eventually standardise the use of formalised business process patterns for initialising and operating construction projects. First of all the workflow-management concepts can be applied. However, current project/process management systems provide only little user support to select and instantiate the most appropriate workflow patterns for the tasks that have to be performed, in regard to the project goals and restrictions. Thus, the performance and

eWork and eBusisness in architecture, engineering and construction

428

success of the project are essentially depended on the knowledge and experiences of the project manager. In order to develop a project/process management support system various aspects have to be considered, namely: (a) analysing the requirements for the underlining organisational and technical aspects of the project, (b) identifying the context parameters, which influences the instantiation and operation of project activities, (c) developing a methodology to extract these parameters from different data sources (that comprises implicit as well as explicit available information), (d) designing a workflow language to model standardised, generic business processes, (e) developing domain specific process pattern that identify actors and roles for each individual activity and associate these activities with information like communication and standardisation requirements. An approach to identify and classify different influence factors for scheduling construction projects is introduced in Chapter 3.1. This comprises the classification of geometrical and object information as well as organisational and functional characteristics. We propose to use these parameters for selecting the dedicated workflow pattern that has to be instantiated to specify a task. The required information for the parameters can be extracted from various data sources like cost models, product models, or project management systems or entered manually. An example for construction specific process pattern is given in Chapter 3.2. Figure 6 provides a schematic sketch of a framework integrating the required services for such a project/process management support system. The basis of the framework is a library of various process patterns generally describing workflows to perform a certain construction task, for example ‘Development of the structural system’. These process patterns define the tasks, their sequences, the actors, and the resources/ information needed to perform it. To control a process pattern in a workflow management system the required actors and information has to be instantiated. This will be performed in cooperation with the VO structure of the project and the deployed information system. For example new partners have to be integrated or responsibilities have to be shifted while information will be exchanged through certain interfaces. To instantiate the appropriate process pattern from the process pattern library the identified influence parameters for the specific work package have to be determined from the Project-Type Organisation and the Project Structure-Scheme. Based on this information the most suitable process pattern can be selected and adjusted to the project requirements. In order to allow for an efficient operation of the framework it is essential to model various workflow patterns for different purposes, phases, objects, and functions. These patterns have to be defined in a manner that they can be (semi-) automatically instantiated by the workflow-management-system according to the available context parameters. Using the introduced Process Matrix as a first source for the process pattern library will foster the

Modelling collaborative processes for virtual organisations

429

Figure 6. Framework for modelling collaborative business processes for Virtual Organisations in the building industry. modelling and operation of Virtual Organisations as well as their information management since: 1. The sender and recipient of the process information is determined. 2. Communication requirements to perform the tasks are specified.

eWork and eBusisness in architecture, engineering and construction

430

3. Data standards are suggested for each task. 4. More than 250 construction related processes are stored in the database. Thus, the operation of collaborative processes for VOs in the building industry are already supported and facilitated to a certain extent. According to the lifecycle phase, the organisational structure, and functional aspects a dedicated Process Matrix entity can be instantiated. Consequently, the communication requirements and data standards for the tasks are predefined. In future, this framework can be enhanced by two further perspectives: 1. Improving the Process Matrix in a way, that the activities can be scheduled (i.e. appointing the time to perform a task) according to the project requirements and goals. Therefore, control parameters have to be introduced. 2. To reduce the complexity of a project it should be separated into different hierarchical layers. With the development of these layers (Keller et al., 2003 proposes three layers) it is possible to decompose the complex design and construction processes into different stages of granularity.

5 CONCLUSION The instantiation and operation of collaborative processes in the building industry has been the focus of numerous research projects for several years. However, an overall modelling methodology considering domain specific requirements and restrictions for organisational, fimctional, as well as technical aspects has not been realised so far. The principles of Virtual Organisations have been identified as a first starting point to more thoroughly characterise construction project processes. By establishing a common understanding of the business operations among all project participants, first problems are reduced. Based on requirements for Virtual Organisations in construction projects, the paper introduces an approach using formalised business process patterns. A methodology to structure aspects of construction projects by defining different classification types for the overall project is proposed. Eventually, four different classification types have been identified: Project Organisation Structure, Structuring of Operations, Function- and Object Orientated Project StructuralSchemes. By detecting the classification types for a specific activity of a project the most appropriate process pattern can be instantiated from a library of standardised, generic reference processes. Therefore, the paper explains the use of an extensible reference process library identifying communicating actors, information and communication requirements, applicable standards as well as meta data types. The Process Matrix developed in the ICCI project gives an example for predefined, generic processes in the building industry. This library is the basis for a framework to support collaborative business processes. By means of this framework it is feasible to establish the Virtual Organisation structure as well as the communication requirements and data standards for the activities that have to be performed in the VO.

Modelling collaborative processes for virtual organisations

431

REFERENCES Booch, G., Rumbaugh, J. & Jacobsen, I. 1999. The Unified Modelling Language User Guide, Addison Wesley Longman Inc. Brandenberger, Jurgen, Ruosch, Ernst 1996. Projektmanagement im Bauwesen, Baufachverlag, ISBN: 3-85565-215-5 Camarinha-Matos, L., Afsarmanesh H. 1999. The virtual enterprise concept, In Infrastructures for the Virtual EnterpriseNetworking industrial enterprises, Kluwer Academic Publishers, ISBN 07923-8639-6 Generic Process Protocol: http://pp2.dct.salford.ac.uk/, accessed 03.2004 Greiner, Peter; Mayer, Peter; Stark, Karlhans 2000. Baubetriebslehre Projektmanagement, Viewegs Fachbiicher der Technik,, ISBN 3-528-07706-9 Kagioglou, M., Cooper, R., Aouad, G., Hinks, J., Sexton, M. & Sheath, D.M. 1998. A Generic Guide to the Design and Construction Process Protocol, Res. Report, University of Salford, UK,. http://www.salford.ac.uk/gdcpp/, accessed 12/03. Keller, Martin; Menzel, Karsten & Scherer, Raimer J. 2003. Use of Workflow-Patterns for Process Modelling in the Building Industry. PRO-VE 2003, 4th IFIP Working Conference on Virtual Enterprises, Lugano Switzerland Keller, Martin; Menzel, Karsten & Scherer, Raimer J 2003. Modellbasierte Projektkoordination fur das virtuelle Planungsteam. IKM 2003, Internationales Kolloquium iiber Anwendungen der Informatik und Mathematik in Architektur und Bauwesen, Bauhaus-Universitat Weimar Katranuschkov, Peter; Gehre, Alexander; Scherer, Raimar; Wix, Jefrey & Liebich, Thomas 2004. User Requirements Capture in Distributed Project Environments: A Processcentred Approach; Xth International Conference on Computing in Civil and Building Engineering Weimar; Mertens, P., Griese, J. & Ehrenberg, D. 1998. Virtuelle Unternehmen und Informationsvemrbeitung, Springer, ISBN: 3-540-64643-4 Möller, Dietrich-Alexander, Kalusche, Wolfdietrich 2001. Planungs- und Bauokonomie—Band 1&2: Grundlagen der wirtschaftlichen Bauausfuhrung, 4. Issue; Oldenbourg Verlag;; ISBN: 3486-25497-9 & 3-486-25433-2 Picot, A., Reichwald, R. & Rolf, T.W. 2001. Die grenzenlose Unternehmung—Information, Organisation und Management, GABLER Rösel, Wolfgang 1999. Baumanagement—Grundlagen, Technik, Praxis; Springer-Verlag; ISBN: 3540-66291-X

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Process modelling in building engineering M.Konig, A.Klinger & V.Berkhahn Institute of Computer Science in Civil Engineering, University of Hanover, Germany ABSTRACT: In building engineering every state of design, planning, construction and usage is characterized by specific processes. These processes can be organized very efficiently with the support of modern information and communication technology. Within the research project “Relational Process Modelling in Co-operative Building Planning” a process model is described by three parts: an organization structure with participants, a building structure with states and a process structure with activities. The project is part of the priority program 1103 “Networkbased Co-operative Planning Processes in Structural Engineering” which is promoted by the German Research Foundation (DFG). This paper covers the concept of the mathematical model for relational planning processes.

1 INTRODUCTION Planning processes in building engineering are described by a process model and a product model: The process model defines the time dependent planning tasks, which can be assigned to different specialized planning participants. The product model includes information on the building elements and their relations within the context of the whole building. This information consists of product data, CADdata and related documents. Within the research project the process model is described in detail. Related projects in the priority program 1103 are dealing with the definition and the software implementation of product models. The planning process of a building is subdivided into three sub models: an organisation structure, a building structure and a process structure. The consistency of these three sub models is provided by process management based on methods of graph theory. The process model and the corresponding relations are outlined in Figure 1. 2 ORGANISATION STRUCTURE The cooperative planning process requires an organisation structure for planning participants and their different planning roles. This organisation structure is project related and can be changed during the term of the planning process. Planning participants represent planning actors, planning groups, offices or subcontractors. For every planning participant one or more planning roles

Process modelling in building engineering

433

Figure 1. Process model and product model. can be defined. To carry out planning tasks certain planning roles are required. Planning participants and planning roles are managed in two sets. Roles are assigned to participants by a n:m relation. These disjunct sets of roles and participants in combination with the corresponding relation build up the bipartitegraph O. (1) R

Set of roles

P

Set of participants

Z

Relation between roles and participants

Before a participant can start to perform a task he has to obtain all necessary data from the product model. The building structure acts as an interface to the product data. After finishing a task the participant has to add all results to the product model. In addition it is his duty to report any conflicts arising from the execution of his planning activities. 3 BUILDING STRUCTURE

eWork and eBusisness in architecture, engineering and construction

434

The building structure covers the planning states of all building elements including the references to the product model. Relations between components are defined by connections. Within the context of planning processes the building structure only contains topological information on building elements. All information on dimensions, material and documents are subject of the product model. Components and connections of a building form a bipartite undirected graph. During the term of planning processes components and connections can be specified in more detail by decomposing the graph structure. This recursive decomposition leads to a topological building structure which is represented mathematically by a hierarchical bipartite undirected graph. S:=(C, F; R, RT, fCF) (2) C

Set of components

F

Set of connections

R R

Relations between components and connections T

fCF

Relations between connections and components Mapping for the composition of components and connections

The consistent composition of components and connections with their relationships is important for further analysis. The hierarchical bipartite undirected graph is consistent, if an undirected relationship on a higher level is associated with an undirected relationship on a lower level and vice versa. The following logical expressions are necessary conditions for the consistency of the building structure.

Figure 2. Topological building structure.

Process modelling in building engineering

435

(3)

(4)

For each component and for each connection a planning schedule with an ordered set of planning tasks has to be defined. Every task has a certain planning state with references to the corresponding objects or documents of the product model. The planning of a component or connections is finished, if all tasks are carried out. 4 PROCESS STRUCTURE The process structure covers all planning activities. Activities represent work packages carried out by planning participants within a prescribed time period. They are specified on the basis of planning schedules for components and connections. 4.1 Structure The entire planning process of a project is decomposed into basic activities which are also called phases. Typical basic activities are the feasibility phase, design phase and construction phase. The directed relationships from one activity to a successive activity are specified by transitions. Activities and transitions form a bipartite directed graph which is acyclic and is called workflow graph.

eWork and eBusisness in architecture, engineering and construction

436

Figure 3. Planning schedule of a building component. The following rules are introduced to realize parallel or alternative execution of activities and transitions. These rules, illustrated in Figure 4, form the basis for checking the structural correctness of workflow graphs. A decision (xor-split) is modelled if a transition has more than one successor. In this case only one of the following activities can be chosen and will be executed. A contact (xor-join) is modelled if a transition has more than one predecessor. In this case the execution of exactly one of the predecessors must be guaranteed. An asynchronization (and-split) is modelled if an activity has more than one successor. In this case all following transitions will be executed. A synchronization (and-join) is modelled if an activity has more than one predecessor. In this case it must be guaranteed that all predecessors are executable. During the planning process defined activities and transitions can be specified in more detail. This recursive decomposition process leads to a process structure which is represented mathematically by a hierarchical bipartite directed graph. The similarity of the process structure and the building structure allows a generalized implementation of the topology of both structures. P:=(A, T; R, Q, fAT) (5) with A

Set of activities

T

Set of transitions

R

Relations between activities and transitions

Q

Relations between transitions and activities

fAT

Mapping for composition of the activities and transition

The hierarchical bipartite directed graph is consistent, if a directed relationship on a higher level is associated with a directed relationship on a lower level and vice versa. For the correct execution of the activities the structural correctness of the process structure must be guaranteed. The process structure is correct, if there are no deadlocks and no lacks of synchronization.

Process modelling in building engineering

437

Figure 4. Rules for activities and transitions.

Figure 5. Hierarchical process structure. A deadlock as shown in Figure 6 arises, if after a decision alternative activities are merged by a synchronization. In this case the synchronization activity can not be executed. A lack of synchronization as shown in Figure 6 arises, if asynchrony activities are merged by a contact. In this case the following activities would be executed more than once. Deadlocks and lacks of synchronization are detected by hierarchical instance subgraphs. Every hierarchical instance subgraph describes one possible workflow without decisions. An algorithm for building hierarchical instance graphs is presented in Konig (2004).

eWork and eBusisness in architecture, engineering and construction

Figure 6. Deadlock and lack of synchronization.

438

Process modelling in building engineering

439

Figure 7. Hierarchical instance subgraphs.

eWork and eBusisness in architecture, engineering and construction

440

Figure 8. Consistent labelling of a hierarchical process structure.

4.2 Criticalpath method The observance of time schedule for the planning process is very important. If an activity is not completed by a certain time the whole planning process could get delayed. The planning and observance of a time schedule is one important task for process modelling. For time scheduling the critical path methods can be used. They can be transferred in generalized form to bipartite graphs. The consideration of the hierarchy requires additional consistency conditions. For each activity a participant needs a certain time to finish. Therefore each activity is labelled with a positive real time value. A transition specifies a relationship between activities. For time scheduling different types of relationships are defined. For a planning process it is sufficient to describe a transition with a minimal time lag between predecessor and successor activity. If the time lag is negative these two activities can be handled parallel. If the time lag is positive a waiting time between these activities exists. Each transition is labelled with a real time value. For critical path methods the hierarchical directed bipartite graph is extended by a label mapping for activities and transitions. P:=(A, T; R, Q, fAT, w) (6) with P

Labelled process structure

w

Labelling of activities and transitions

Process modelling in building engineering

441

The critical path for each level of the hierarchy of a labelled hierarchical bipartite graph can be calculated with the well-known critical path methods. If the hierarchical graph is consistently labelled, the length of a

Figure 9. Consistent marking of a hierarchical process structure. critical path on an upper level is an upper bound for the length of a critical path on a lower level. The consistency of the labelling has to be verified. For each decomposition of an activity on a lower level there is a labelled bipartite partial graph. The labelling is consistent if the critical path length of the partial graph is not greater than the labelling of corresponding activity. w(x)≥P(x) (7) w(x)

Label of x

P(x)

Length of critical path in partial graph

4.3 Petri nets For the process structure the methods of simple Petri nets are used to realize an event oriented communication. The hierarchy leads to additional conditions for the consistent marking of the process structure. Each activity is in a certain state at any time. For an event oriented communication two different states of an activity are defined: not completed and completed. Each activity is marked by 0 (not completed) or by 1 (completed). A transition is active if all predecessor activities are completed and all successor activities are not completed. Each transition is marked by 0 (not active) or by 1 (active). For the application of simple Petri nets the hierarchical process structure is extended by a mapping for the marking of the activities and transitions. P:=(A, T; R, Q, fAT, m) (8)

eWork and eBusisness in architecture, engineering and construction

442

with m

Marking of activities and transitions

The marked process structure is extended by exactly one start transition and exactly one end transition. The initial condition of the marked process structure is defined as: each Transition without predecessors is marked with 1 and each transition with predecessors and each activity is marked with 0. The consistency of the marking of a hierarchical process structure has to be checked. Each decomposed

Figure 10. Marked process structure with a decision situation. activity is completed, when all activities of the decomposition are completed. The consistency conditions for transitions are based on the firing rules of transitions in Petri nets. These conditions can be described in vector and matrix form. With the initial marking of transitions and the actual marking of activities the actual marking of transitions can be checked. An event oriented communication for planning processes is supported by a marked hierarchical process structure and Petri net methods. An activity can start if all predecessor transitions are active. Thereupon the planning participant is notified. If the participant reports the completion of an activity, the activity is marked with 1. The marked hierarchical process structure has to be updated. Planning decisions obstruct the automation of an event oriented communication system. If a decision transition (xor-split) is active the automatic process flow has to be stopped. The obstruction of the process has to be solved interactively by a participant with an appropriate role. If one of the successor activities is selected to be executed the associated participant can be notified. 5 RELATIONS BETWEEN SUBMODELS Three binary relations with conditions exist between the three structures of the process model. At least one planning role of the organisation structure is required in order to perform a planning task of the building structure. The dependencies between planning tasks and planning roles are defined by a binary n:m relation.

Process modelling in building engineering

443

(9) T

Set of tasks

R

Set of roles

SO

Relations between tasks and roles

Every planning task is mapped to exactly one planning activity of the process structure. An activity can be related to more then one task. fSP:T→A (10) T

Set of tasks

A

Set of activities

fsp

Mapping of tasks to activities

Figure 11. Relations between the three sub models. An activity is carried out by exactly one planning participant of the organization structure. The mapping between participants and activities describes the third binary relation. fPO:A→P (11) A

Set of activities

P

Set of participants

eWork and eBusisness in architecture, engineering and construction

fpo

444

Mapping of activities to participants

During the composition of the relations between the three structures the consistency must be considered. A activity can only be assigned to a participant, if the participant has all planning roles of the tasks of the activity. (12) R(a)

Set of roles of all tasks of an activity a

R(p)

Set of roles of a participant p

These relations can be used to navigate through the hierarchical process model. In order to manage the complexity of the entire planning process the hierarchical structures for the building and the process can be supportively adopted. 6 PROCESS MANAGEMENT Methods for the process management are defined on the basis of the formal description of the process model. The methods are used for coordinating und controlling the entire planning process. The graph theory allows a formal definition of these methods. For example a planning participant can use the methods to find all references for a component of the building structure in the product model or to find all activities with their associated building elements which a participant has to process. The formal description of the methods and the whole process model are a good precondition for a simple software implementation. For this project the structures, conditions and methods have been implemented in the programming language JAVA (Konig 2004). 7 SUMMARY In this paper a concept for a process model for planning processes in building engineering is presented. The relational process model consists of an organization structure with planning participants, a building structure with planning states and a process structure with planning activities. These sub models are mathematically described on the basis of relation theory and graph theory. The building structure and the process structure are represented by hierarchical bipartite graphs. These hierarchical structures support the dynamical aspects of cooperated planning processes in building engineering. The consistent and correct composition of the relational process model is very important. To ensure consistency and correctness of the compositions, conditions as well as methods for coordination and controlling of the planning process are formally defined. The structures, conditions and methods have been implemented prototypically and were used in extracts for an example project.

Process modelling in building engineering

445

ACKNOWLEDGEMENT The authors thank gratefully the German Research Foundation (DFG) for supporting the research project “Relation Process Modelling in Co-operative Building Planning” embedded in the priority program 1103 “Network-based Co-operative Planning Processes in Structural Engineering”. REFERENCES Berkhahn, V. & Esch, C. 2003. Re-Engineering of Objects in Construction Drawings. In: R. Amor (ed.), Construction ITBridging the Distance, CIB Report: Publication 284, Proc. of CIB W78’s 20th International Conference on Information Technology for Construction; Auckland, New Zealand. Berkhahn, V., Kinkeldey, C., Schleinkofer, M. & Rank, E. 2004. Re-Engineering Based on Construction Drawings-From Ground Floor Plan to Product Model. In: Proceedings of the 10th International Conference on Computing in Civil Engineering and Building Engineering (ICCCBE); Weimar, Germany. Berkhahn, V. & Klinger, A. 2004. Relationale Prozessmodellierung in kooperativer Gebdudeplanung—Zwischenbericht tiber die 2. Forderphase. DFG Schwerpunktprogramm 1103, http://www.dfg-sppl/ 103.de. Damrath, R. & Konig, M. 2002a. Relational Modelling of Planning Processes in Building Engineering. In: Proceedings of the 9th International Conference on Computing in Civil and Building Engineering (ICC-CBE); Taipei, Taiwan. Damrath, R. & Konig, M. 2002b. Relationale Prozessmodellierung in kooperativer Gebdudeplanung—Zwischenbericht uber die 1. Forderphase. DFG Schwerpunktprogramm 1103, http://www.dfg-sppl/ 103.de. Desel, J. & Esparza, J. 1995. Free Choice Petri Nets. Volume 40 of Cambridge Tracts in Theoretical Computer Science, Cambridge University Press, Cambridge. Klinger, A. 2003. Strukturanalyse von Workflow-Graphen. In: Tagungsband des 15. Forum Bauinformatik in Hannover, Shaker Verlag Aachen, Germany. Konig, M. 2004. Ein Prozessmodell fiir die kooperative Gebdudeplanung. Dissertation, University of Hannover, Germany. Konig, M. & Klinger, A. 2002. Modellierung von Planungsprozessen mit Hilfe von Hierarchischen Strukturen. In: Tagungsband des 14. Forum Bauinformatik in Bochum, Fortschrittsberichte Reihe 4, Nr. 181, VDIVerlag Diisseldorf, Germany. Konig, M., Klinger, A. & Berkhahn, V. 2004. Structural Correctness of Planning Processes in Building Engineering. In: Proceedings of the 10th International Conference on Computing in Civil and Building Engineering (ICCCBE); Weimar, Germany. Lin, H., Zhao, Z., Li, H. & Chen, Z. 2002. A Novel Graph Reduction Algorithm to Identify Structural Conflicts. In: Proceedings of the 34th Annual Hawaii International Conference on System Science, IEEE Computer Society Press. Meipner, U.F., Rüppel, U., Greb, S. & Theip, M. 2003: Network-based Cooperation Processes for Fire Protection Planning. In: R. Amor (Ed.): Proceedings of the CIB W78’s 20th International Conference of Information Technology For Construction, S. 231–238, University of Auckland, New Zealand. Pahl, P.J. & Damrath, R. 2001. Mathematical Foundations of Computational Engineering—A Handbook. SpringerVerlag, Berlin, Germany. Rüppel, U., Meipner, U.F. & Greb, S. 2003. Vernetzte Bauprozesssteuerung auf der Basis bauteilspezifischer Prozessmuster fur geotechnische Konstruktionselemente. In: Gürlebeck, K.

eWork and eBusisness in architecture, engineering and construction

446

(Hrsg.); Hempel, L. (Hrsg.); Konke, C. (Hrsg.): digital Proceedings, 16. Internationales Kolloquium tiber Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (ikm 2003; Tagungs-CD-ROM), Weimar, Germany. Sadiq, W. & Orlowska, M.E. 1999. Applying Graph Reduction Techniques for Identifying Structural Conflicts in Process Models. In: M.Jarke and A.Oberweis (editors) Proceedings of the llth International Conference on Advanced Information Systems Engineering (CAiSE’99), volume 1626 of Lecture Notes in Computer Science, pages 195–209, Springer-Verlag, Berlin, Germany. Van der Aalst, W.M.P., Hirnschall, A. & Verbeek, H.M.W. 2002. An Alternative Way to Analyze Workflow Graphs. In: Proceedings ofthe 14th International Conference on Advanced Information Systems Engineering (CAiSE’02), volume 2348 of Lecture Notes in Computer Science, pages 535–552, Springer-Verlag, Berlin, Germany.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Space competition on construction sites: assignment and quantification utilising 4D space planning tools Z.Mallasi & N.Dawood Centre for Construction Innovation and Research, The School of Science and Technology, The University of Teesside, Middlesbrough ABSTRACT: This study addresses the problem arising on all construction sites: the occurrence of workspace interference between construction activities. From a site space organisation and planning context, this problem can lead to an inevitable roadblock to the progress of the scheduled construction operations. In real situations, when the spatial congestions occur, they could reduce productivity of workers sharing the same workspace and may cause health and safety hazard issues. The aim of this paper is on presenting a computer-based method and developed tool to assist site managers in the assignment and identification of workspace conflicts. The authors focus on the concept of ‘visualising space competition’ between the construction activities. The concept is based on a unique representation of the dynamic behaviour of activity workspace in 3D space and time. An innovative computer-based tool dubbed PECASO (Patterns Execution and Critical Analysis of Sitespace Organisation) has been developed. The emerging technique of 4D (3D+time) visualisation has been chosen to yield an interesting 4D space planning and visualisation tool. A multicriteria function for measuring the severity of the workspace congestions is designed, embedding the spatial and schedule related criteria. The paper evaluates the PECASO approach in order to minimise the workspace congestions, using a real case study. The paper concludes that the PECASO approach reduces the number of competing workspaces and the conflicting volumes between occupied workspace, which in turn produces better assessment to the execution strategy for a given project schedule. The system proves to be a promising tool for 4D space planning; in that it introduces a new way of communicating the programme of work.

1 INTRODUCTION 1.1 Problems in visual workspace planning Communicating the construction schedule and strategy of work among the project team members is a unique problem that takes place in most construction sites. This problem is

eWork and eBusisness in architecture, engineering and construction

448

even cumbersome as the built facility generates complex shapes of occupied sitespaces by the executed construction processes. The ideal solutions in traditional space-time planning techniques, have involved textual description, hand sketches with site layout templates, a number of graphical technologies, including bar charts, network diagrams, and 2D/3D scaled visualisation models (Morris, 1994). However, there are shortcomings of techniques in forming a visual representation of the construction execution workspace: – Activity workspace execution: Considering the Gantt chart a favourable technique, planners are not capable of communicating visually the execution strategy and plan. In other words, the Gantt chart can be thought of as a ‘what to do’ list and sequence of assignments concerning the construction activities. Cheng and O’Connor (1996) claim that, in field practice, construction planners have to interpret space information into poor visual descriptions. However, they do not seem to convey the dynamic behaviour of construction activity workspace in 3D space and time. – Mental rehearsal of site operations: Mawdesley et al., (1997) explained that Gantt chart techniques do not furnish a communication medium on how the project activities on the construction site are to be executed. During the construction phase, the format of Gantt chart does not ‘capture’ the visual interaction between the site operations. Consequently, the Gantt chart is not entirely adequate for rehearsing site operations, both in space and time. – Loss of productivity: Productivity problems were investigated by Kaming et al. (1998) and showed that inappropriate workspace planning caused interferences between subcontractors. Many frequent visits by the workforce had occurred in some zones of the building, which resulted in work interruptions. There is evidence to suggest that workspace interference was a factor in decreasing productivity of work by 40%. 1.2 What was neglected in construction workspace-time planning exercise? Four important issues, therefore, were not highlighted in 4D workspace-time planning. They are: – Execution strategy representation: Traditional workspace-time planning methods, such as the space-time Chainage charts and layout motion diagrams, in their most general forms, are ambiguous. Construction planners often express the coordination of the planned schedules based on highly generalised conceptual space terms, such as North, South, East and West. Take an example of a construction planner conveying the execution of – GroundFloor Steel Columns activity to begin from the East and progressing towards the West. The execution plan of such an activity is left to the workmen on the site. In such manner, work interruptions between site operations might occur (Mallasi & Dawood, 2001), especially in large complex construction projects, where the site space involves a number of constrained site operations. – Construction progress state simulation: The weekly visualisation technique used for the construction progress state is not realistic. Previous site layout planning applied such techniques from a factory/plant perspective that only featured linear patterns of direction for the produced work (Zouein and Tommelein, 1999). This research

Space compettion on construction sites

449

proposes a time-based 4D simulation of the activities execution workspace as the construction progress state changes dynamically – Planning in three-dimension: Planning and analysis of construction workspace inside the building requires a three-dimensional approach. In some situations, for example, workspace conflicts could exist in different floors of a building project (Cheng & Yang, 2001). Planners in some construction situations, such as the plant and equipment operation, need to analyse space three-dimensionally External site layout techniques using the Grid System neglecting the analysis of spatial information in 3D, and applied 2D approach that only dealt with horizontal workspace conflicts. – Workspace-time connectivity analysis: In building construction, workspace-time connectivity analysis should be based on the intervals where activity execution workspace changes over points-in-time. Nowadays, the accepted view of most researchers is that space has properties related to things, explained Hillier (1996). Further, it is highly acknowledged

Figure 1. The two planning levels along the project stages including the four workspace planning tasks. that workspace behaviour is ‘connected’ and relative to its defined properties. From one perspective, research in workspace planning did not provide workspace connectivity mechanism, so that to encapsulates the activity workspace behaviour at any point-in-time. 1.3 Indusion of specific visual planning features Figure 1 indicates two levels of project planning: stra tegic and operational. This study elaborates on improving the conventional visual space planning features, utilised in the operational level. As revealed by Gardiner & Ritchie (1999), the planner systematically involves their technical judgment when making the decisions about what tasks will be performed, how the tasks will be performed, restrictions on how to perform them, and who will perform the tasks.

eWork and eBusisness in architecture, engineering and construction

450

To some extent, these decisions are of a spatial nature and they do not appear to have the adequate visual representation in the traditional planning methods. There are four workspace planning tasks (Fig. 1) that can be highlighted during project planning stages: (1) developing a space concept of the built facility (2) planning the workspace requirement based on the construction method and physical resources (3) the Critical Space Analysis (CSA) of workspace conflicts, and (4) the detail output of work execution strategy. From the above, three main visual features are studied to help in generating 3D visual representation of the activities workspace configuration are: – Visualising quantities of work: Planners realise the importance of recording the progress of construction work at weekly intervals, then presenting it on a Gantt chart. This work, therefore, suggests three types for work rate distributions to be included in the 3D visualisation: Uniform, High-Low, and Low-High distribution. In this respect, the example shown in Figure 2 explains the significant correlation between the activity behaviour at a point-in-time and its completion, based on the three types of work rate distribution.

Figure 2. Activity-behaviour at pointin-time based on the three types of work rate distributions (after Mawdesley et al., 1997).

Figure 3. Illustration of two examples out of twelve EP types showing the mechanism of the PW and EW directions.

Space compettion on construction sites

451

– Workspaces location and overlap in time: Representation of the physical location of workspace overlap between progressing activities across the horizontal and vertical space (3D+time). This is a simple feature acquired from the space-time Chainage overlapping method in one-dimensional space (1D+time). This representation, therefore, is suitable by means of giving an indication of where and when activities workspaces take place. – Execution Patterns (EP): Planners analyse the execution strategy of work utilising Site Layout Motion diagrams (Roberts, 1998). This technique has been utilised in many literature to optimise the facility and site layout planning (Zouin & Tommelein, 2001). Equally, EP have been recognised by Riley & Sanvido (1997) as an important element in workspace planning. Visualisation of the motion diagrams technique and the EP is improved in this study by visualising the activity execution strategy in twelve EP. This research project automates the above twelve EP in the 4D workspace planning. The overall combinations of these EP facilitate 4D visualisation of ‘what-if’ scenarios based on Progress of Work (PW) direction and Execution of Work (EW) direction that are considered perpendicular to each other in Universal 2D Cartesian space (Fig. 3). Execution patterns are divided into two main categories. The first is the cardinal category (Fig. 3a), which occurs as a result of referencing the PWin the main cardinal directions and the EW perpendicular to it. This category produces four EP types (e.g. PW being executed from the West to the East, and the EW’m both directions of North and South). The sub-cardinal directions are in the second category, which results in the eight EP types (e.g. PW being executed from North to South, and the EWbeing executed from the east-west accessed from northeast). 2 ENABLING TECHNOLOGY OF 4DVISUALISATION 4D construction visualisation is becoming a popular technique in the construction planning. For the last fifteen years, both practitioners and researchers in construction management realised the great promise of such emerging visualisation techniques. Nowadays, the Construction Industry is becoming familiar with the uptake of 4D models to improve visualisation of construction schedules. 2.1 What is 4D-CAD visualisation? The most common about 4D-CAD visualisation is that it brings together the Gant chart schedule information (using any project scheduling software like MS Project®) and three-dimensional components of a construction project (using any CAD software). In 1987, the development of the first generation of 4D project scheduling were initiated by the engineering and construction firm Bechtel, in collaboration with Hitachi Ltd. and exploited the characteristics of the fourth dimension (Rischmoller & Alarcon, 2002). This firm, together with the Martin Fischer research team, from Stanford University, formulated the original technique and basis of visual 4D models, linking project schedule to the 3D CAD model to simulate the construction sequence. The goal of the visualisations is meaningful for sharing experience among the project team.

eWork and eBusisness in architecture, engineering and construction

452

Many researchers have addressed the concept of 4D-CAD in construction management. Although 4D visualisation does not quantify workspace conflicts between the construction processes, there were several research attempts in academia. Some examples can be found in the work by: Akinci et al. (2000a) who formalised construction workspace types and taxonomy; Akbas et al. (2001), identified 4D visualisations technique using construction zone generation. 4D-CAD space visualisation has also been identified throughout the Virtual Construction Site (VIRCON) project a UK research initiative to develop a decision support system for construction project planning (Mallasi & Dawood, 2002); the technical survey of 4D-CAD research by Heesom & Mahdjoubi (2002) have benchmarked the construction knowledge, framework, and resources necessary to develop 4D models. The next sections of this paper elaborate on the basics for quantifying workspace conflicts utilising the visual feature identified earlier in this paper. 3 THE CONTEXT FOR WORKSPACE COMPETETION 3.1 Rational for Critical Space-time Analysis (CSA) The proposed CSA associates the visual features for workspace planning with the workspace competition. CSA deals particularly with analysing the space-time competition that occurs between construction operations. Therefore, CSA verifies the occupied workspaces by construction operation as competing together. The focus will be on how to quantify the nature of this competition, by assessing criticality of the workspace conflicts sharing the same space (Fig. 4, a & b). The key assumptions are that the dynamic nature of workspace usage and change should be traced continually and so accommodate space connectivity in the fourth dimension. Once the space connectivity mechanism is established, it would then be possible to quantify the particular effect of critical spaces on the construction work progress. Hence, the PECASO prototype was developed in this work to evaluate the outcome of the CSA (Fig. 4). The 4D-CAD prototype integrates MS Project® scheduling application with the AutoCAD® ADT, via the MS Access® database. A graphical user interface (GUI) is built on top of AutoCAD, utilising the advanced features of Visual Basic for Applications (VBA) programming. 3.2 Use of past classiflcation of workspace conflicts For the purpose of analysing the workspace competition, the CSA mechanism must provide a reasoning mechanism, in order to minimise the criticality of a construction workspace. If a workspace conflict is expected to occur in a specific week, for example, questions, such as ‘which space-types are expected to interfere during that week?’ and ‘what is the severity and knock-on-effect of such interference on the construction progress?’ must be raised. By providing answers to these questions, the severity (i.e. degree of space-conflict) of the interference can be assessed and work execution adjusted, to allow increase in the productivity of workers on the job.

Space compettion on construction sites

453

Figure 4. Framework of PECASO tool utilising 4D-CAD visualisation of CSA and workspace competition visualisation. Originally, the established theoretical approach for classifying the clash types, was developed by Akinci et al., (2000a), space-time conflict taxonomy. The space-time taxonomy considers the conflicting spacetypes among the properties for classifying the clash types (Fig. 5). The outcome from this is a classification to include the main clash types like congestion, damage, and safety hazard. The result from this taxonomy is the detailed sub-clashes of the main clash types—because different level of congestion might exist on site. As can be noticed in Figure 5, it has been practical in this research to rank the severity of workspace clash types. Some conflict types were added, such as work interruption, space obstruction and access blockage. 3.3 How can workspace conflicts be quantifled? The immense amount of spatial data related with the analysis of activity construction workspace emphasises the importance of developing the CSA quantification approach. This is a complex issue and an on-going area of research that has started to receive some attention among the construction research community The crucial point that is beginning to emerge is the determination of the variables associated with the measurement of space criticality, therefore minimising the severity of workspace conflicts. This study developed the quantification approaches for CSA, based on literature survey presented in

eWork and eBusisness in architecture, engineering and construction

454

Figure 5. Review of theoretical approaches for classifying ranking to workspace conflicts. Table 1. The table shows clearly the gaps in the justification of an approach for obtaining the related space properties in critical space-time analysis; also in terms of linking the measurement of the space conflict to the criticality, or severity, of that conflict. As a consequence, there are currently no ‘mature’ benchmark quantification approaches to spatially analyse and enable a measurement of the performance of the construction schedule. The next subsection describes the proposed measurement and assessment for quantifying the workspace competition. 3.4 Proposed quantification method The proposed assessment of workspace competition quantifies the CSA value. In the interest of CSA, therefore, a multi-criteria evaluation function has been developed. The multi-criteria fimction will provide a measurement for CSA value, and so values the different criterion for the construction schedule and the workspace data. The multicriteria function utilises weighting between the multiple criteria. Ramulu & Kim (2003) believe that multi-criteria function measurement is the first important step to formulating a solution to the problem. The multi-criteria function comprises of the sum of five schedule and spatial related criteria, using various weight coefficients for each criterion. Figure 6 illustrates an abstract example for applying the calculation of the CSA value, based on Equation 1. This study has developed the multi-criteria function fA(scr) for the possible conflicts between A number of activities during monitoring period D (per week) as follows:

Space compettion on construction sites

455

(1)

where f(scr)=the project schedule space criticality calculated value; f(co)=the criteria fimction for the percentage of conflicting workspace. Where (2)

f(r)=the criteria function for the total number of workspace conflicts with respect to the rankings; f(no)=the criteria function for the total number of conflicting activities; ƒ(st)=thecriteriaftmctionforthe conflicting space types; f(cr)=the criteria function for the critical activities (1 for critical and 0 for non-critical); vwi=the weighted coefficients for each criteria in the function fA(scr). The weighting coefficients vwi (sometimes referred to as variable weights) are an estimated measure for each criterion governing a priority scheme. By doing so, the performance of the value of fA(scr) fimction can be assessed. Although these coefficients could be obtained through trial and error, they could also be user-deflned values from the project planner. This is

Table 1. The theoretical approaches for identifying space and clash types. Properties and quantification approaches Author(s) Variables & date

Preserve Volume Work Conflict Conflict Visualisa Optimisa Apply CSA conflict space details ranking tion tion CPA analysis types medium approach criteria and priorities

Thabet - Space and Capacity Beliveau Factor (1994)

No

Yes

No

No

No

CAD

Akinci etal. (2000a)

–Conflict Ratio – Clash severity sub classifica tion

No

Yes

Not all

Yes

Yes

4D-CAD N.A.

Guo (2002)

–Inter No ference Space Percentage –Inter

Yes

Yes

No

No

4D-CAD Manual Yes reschedul ing

N.A.

No

Yes

eWork and eBusisness in architecture, engineering and construction

456

ference Duration Percentage Winch (2003)

–Spatial Loading

Yes

No

Not all

No

No

4D Evolution Yes CAD/VR ary algorithm (brute force)

Figure 6. Examples showing the developed approach for calculating the critical space-time analysis (CSA) value ƒ(scr), most preferable, as explained by Chang et al., (2002), because the value for each weight will be given, according to the ‘relative importance’ of the criteria attached to it. Generally, the sum of these weights should satisfy the following conditions: (3)

VW(i)=VW(1)+VW(2)+VW(3)+VW(4)+VW(5)=1

and: 0≤vw(i)≤1 (4) The values for in Equation (3) are the measures of priority for each criterion that is chosen by the project planner. These values range from Zero to One: more important criteria will get a higher weight, and less important criteria will get lower weights.

Space compettion on construction sites

457

3.5 Implementation oftime-based 4D simulation A key concept in the visualisation of workspace competition is the technique for simulating construction product and processes in a time-based fashion. The time-based simulation mechanism involves the construction progress state in space-time and is done dynamically. Research by Kamat & Martinez (2001) confirmed that 4D time-based simulation was suitable and highly scalable in designing a generic 4D visualisation system. Arguably, representing the activity-workspace change in time is an abstract simulation mechanism to process the change of

Figure 7. The 4D time-based simulation at X-time. activity-workspace behaviour. This way, 4D time-based technique becomes a snapshot of time and workspace simultaneously. The mechanism utilises a visualisation clock as a controller (dates and times) for altering the time forward and backward (Fig. 7). The time-based concept simulates the Quantities of Workper week (QW(prog)) during three time-based frames (or intervals). The first time-based simulation frame (Fig. 7) visualises the ‘progressing’ activity-workspace during ‘X-time’, based on Equation (5) illustrated below. QW(prog)=QW(tot)/AD(tot) (5) where QW(tot)=total quantity of work value obtained from the database; and AD(tot)=total activity calendar duration obtained from the schedule information. The second time-based simulation frame obtains the Quantities of Finished Work (QW(fin)) from previous week(s) ‘before X-time’, which represent the state of completed work. Equation (6) is utilised in identifying this amount of QW(fin).

eWork and eBusisness in architecture, engineering and construction

458

QW(fin)=QW(prog) (this Mon Week-Week) (6) where QW(fin)=quantity of finished work calculated during X_Monitoring_Week (X_Mon Week). The third time-based simulation frame deals with activities that have not started yet ‘after X-time’, and also determines any Unfmished Quantity of Work (QW(unfin)) for progressing activities (Equation 7). QW(unfin)=QW(tot)−(QW(fin)+QW(prog)) (7) where QW(unfin)=quantity of unfinished work calculated during X_Monitoring_Week (X_Mon Week). 4 ASSIGNMENT OF WORKSPACE 4.1 Main techniques found in literature Sirajuddin (1991) and Thabet & Beliveau (1994), propose that construction workspace is a combination of resource gangs, including their equipment and tools. This is a situation where resource gangs operate and manoeuvre equipment within the direct workspace at the activity location. Another typical case is similar to pouring concrete into pad foundations, using a concrete mixer and a concrete vibrator. Sirajuddin suggested that, to some planners, these workspace dimensions could be obtained either from their previous work experience, or from data, such as equipment and tools manuals. Similarly, Akinci et al. (2000b) incorporated a concept for assigning projectspecific space requirements associated with a construction method model into the 4D WorkPlanner Space Generator. The positional information about space was modelled using an allocentric representation (such as, roof scaffolding outside or inside a building envelope). To specify the workspace requirement in a generic way, while satisfying a set of spatial dynamics and change of workspace usage over time intervals, is a difficult problem as there are many alternative space strategies to apply on the logic of work execution. Therefore, it was decided in this research to design the construction workspace based on the Approximation Envelope (AE) that uses a 3D Box to represent the activity workspace (Fig. 8). The AE technique improves previous research efforts, by including the characteristics of workspaces like: above, below, and surrounding (North, East, South, and West).

Space compettion on construction sites

459

Figure 8. The three workspaces properties associated with the 3D AE around a construction product.

Figure 9. Representation of dynamic workspace configuration utilising the 3D AE concept.

4.2 Capture of dynamic requirements for workspace The assignment of workspace based on the 3D AE provides the planners with generic capture of different workspace requirements, according to the nature of the construction activity. The application and concept of the 3D AE for workspace representation is provided in the example in Figure 9. The example shows two construction product groups ‘A’ and ‘B’, and the plant associated with them (Fig. 9, a & b). Even when the location and position of the products groups associated with the construction activity are changed, the assignments of the workspaces are dynamically reconfigured utilising the 3D AE (Fig. 9, c & d). The result is a dynamic representation of the construction workspace that accommodates the construction method for the activities. This AE mechanism eliminates the tedious effort of re-describing the volumetric properties of workspace manually (i.e. marking-up areas of workspaces around products).

eWork and eBusisness in architecture, engineering and construction

460

5 EXPERIMENTAL RESULTS OF WORKSPACE COMPETITION The authors utilised the PECASO 4D tool to experiment with CSA results and hence evaluate the workspace competition concept. The CSA values are obtained after running three scenarios utilising the

Figure 10. Three weeks of workspace variation and minimisation of CSA values ƒ(scr) for three experimental 4D simulation runs. PECASO 4D simulation approach. It was important to consider in the analysis the occupied workspaces by the resources on site like plants, material paths, and storage areas. On a weekly basis, the simulation results were exported to the MS ACCESS database for future evaluation of the space criticality fanction fA(scr). A typical experimental illustration for minimising workspace conflict is shown above in Figure 10 and applied on the School of Health project case study. The simulation began with a max CSA value of 108 representing the actual project schedule (run No. 1). The alteration of the above variables for minimising workspace conflicts indicates a reduction of CSA by 25% less than the original schedule (run No. 3). The reason for this minimisation is due to the variation in EP type for the Ground Flooring Concreting activity (North to South), while the rest of the activities were progressing from the West to the East. At the same time, the occupied workspace by the plant moved to a space free of congestions and reduced the total number of conflicting space types f(st). 6 SUMMARY This paper introduced the workspace competition as a new concept for minimising workspace congestions occurring on construction sites. Visual planning features like:

Space compettion on construction sites

461

twelve execution pattern types, three different work rate distribution types, and timebased QW simulation were identified and implemented in the developed 4D visualisation environment. The design of a multi-criteria function was the core of the PECASO approach for evaluating the CSA value. Based on the experimental results, the PECASO CSA approach is expected to increase the planner’s awareness for workspace planning and become more confidence when using 4D visualisation for communicating the project plans. One could argue that the advancements in 4D space-time conflict analysis relies on capturing the dynamic nature of construction site operations. The results also suggest possible future use of the proposed technique in 4D workspace planning. REFERENCES Akbas, R., Fischer, M., Kunz, J. & Schwegler, B. (2001). Formalizing Domain Knowledge for Construction Zone Generation. Proceedings of CIB w78 2001 Conference on Construction Information Technology, 2001, South Africa, Vol. 1, pp 30–1/30–16. Akinci, B., Fischer, M., Levvitt, R. & Carlson, R. 2000a. Formalisation and Automation of TimeSpace Conflict Analysis. CIFE Working Paper No. 59, June 2000, Stanford University. Akinci, B., Fischer, M., Kunz, J. & Levvitt, R. 2000b. Representing Work Space Generically in Construction Method Models. CIFE Working Paper No. 57, June 2000, Stanford University. Chang, P., Hsieh, J. & Lin, S. 2002. The Development of Gradual-Priority Weighting Approach for the Multi-objective Flowshop Scheduling Problem. International Journal of Production Economics, No. 79, 2002, pp 171–183. Cheng, M.Y. & O’Connor, J.T. 1996. ArcSite: Enhanced GIS for Construction Site Layout. Journal of Construction Engineering and Management, December 1996, pp 329–336. Cheng, M.Y. & Yang, S.Y. 2001. GIS-Based Cost Estimates Integrating with Material Layout Planning. Journal of Construction Engineering and Management, July/August 2001, pp 291– 299. Gardiner, P.D. & Ritchie, J.M. 1999. Project Planning in a Virtual World: information management metamorphosis or technology going too far? International Journal of Information Management, Volume 19, pp 485–494. Guo, S. 2002. Identification and Resolution of Work Space Conflicts in Building Construction. Journal of Construction Engineering and Management, July/August 2002, pp 287–295. Hessom, D. & Mahdjoubi, L. 2002. Technology Opportunities and Potential for the Virtual Construction Site: emerging research initiatives. VIRCON Task Three Technical Report, Vol. 1 University of Wolverhampton, Wolverhampton, UK. Hillier, B. 1996. Space is the Machine, Cambridge University Press, Cambridge. Kamat, V.R. & Martinez, J.C. 2001. Visualising Simulated Construction Operations in 3D. Journal ofComputing in Civil Engineering, ASCE, Vol. 15, No. 4, October 2001. Kaming, P.F., Holt, G.D., Kometa, S.T. & Olomolaiya, P.O 1998. Severity Diagnosis of Productivity Problems—a Reliable Analysis. International Journal of Project Management, Vol. 16, No. 2, pp 107–113. Mallasi, Z. & Dawood, N. 2001. Assessing Space Criticality in Sequencing and Identifying Execution Patterns for Construction Activities Using VR Visualisations. ARCOM Doctoml research workshop: Simulation and modelling in constmction, October 2001, Edinburgh University, UK, pp 22–27. Mallasi, Z. & Dawood, N. (2002). Registering Space Requirements of Construction Operations Using Site-PECASO Model. Proceedings of CIB w78 2002 Conference on Distributing Knowledge in Buildings, 2002, Aarhus School of Architecture, Denmark, Vol. 2, pp 83–90.

eWork and eBusisness in architecture, engineering and construction

462

Mawdesley, M., Askew, W. & O’Reilly, M. 1997. Planning and Controlling Construction Projects: the best laidplans, Addison Wesley Longman, England. Morris, P. 1994. The Management of Projects, Thomas Telford, England. Ramulu, M. & Kim, D. 2003. Drilling Process Optimisation for Graphite/bismaleimide-titanium alloy stack. Journal of Composite Structures, 2003, (in press). Riley, D. & Sanvido, V. 1997. Space Planning Method for Multi-story Building Construction. Journal Construction Engineering and Management, Vol. 123, No. 2, pp 171–180. Rischmoller, L. & Alarcon, L. 2002. 4D-PS: Putting an IT new work process into effect. Proceedings of CIB w78 2002 Conference on Construction Information Technology, 2002, Aarhus, Denmark, Vol. 1, pp 109–114. Roberts, Keith 1998. Construction and the Built Environment: advanced GNVQ, London, Addison Wesley Longman Ltd. Sirajuddin, Abdullah, M. 1991. An Automated Project Planner. PhD Thesis, Department of Civil Engineering, University of Nottingham. Staub, S., Fisher, M., & Melody, S. 1998. Industrial Case Study of Electronic Design and Schedule Integration, Working Paper, No. 48, CIFE, Stanford. Thabet, W. & Beliveau, Y. 1994. Modeling Work Space to Schedule Repetitive Floors in Multistory Buildings. ASCE Journal of Construction Engineering and Management, 120(1), pp96–116. Winch, G.M. 2003. Critical Space Analysis: Planning the Use of Spatial Resources on Projects. Proceedings 3rd Nordic Conference on Construction Economics and Organisation, Lund University, pp 375–392. Zouein, P.P. & Tommelein, I.D. 1999. Dynamic Layout Planning using a Hybrid Incremental Solution Method. Journal of Construction Engineering and Management, Vol. 125, No. 6, November, 1999, pp 400–408.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Project planning: a novel approach through a universal e-engineering Hub—a case study of seismic risk analysis G.Augenbroe College ofArchitecture, Georgia Tech, Atlanta, USA Z.Ren, C.J.Anumba & T.M.Hassan Department of’Civil & Building Engineering, Loughborough University, UK M.Mangini Geodeco S.P.A., Italy ABSTRACT: The e-HUBs project has conceived and developed a novel approach to web hosted e-engineering services. Focusing on Project Planning, the e-engineering Hub facilitates the outsourcing of engineering services and the fast creation of a project plan that can be executed by design engineering teams. This paper presents the e-Hub through a testbed demonstrator produced as a result of this project. It first introduces the key concepts of the e-Hub; then presents the seismic engineering scenario with focus on the role and services of the eRiskZone portal and its seamless integration with the e-Hub. The focus is on the workflows and related attribute templates as well as the supporting engineering services developed for this scenario.

1 THE e-ENGINEERING HUB 1.1 Overview Most companies are recognizing that partnerships are critical to their future success. Rather than betting on the “extended enterprise” formula, companies express the desire to engage in on-the-fly partnerships. Ad-hoc partnering in project specific dynamic settings provides the agility that long term strategic alliance based partnering cannot guarantee. It is this realization that has companies looking for support to initiate and plan partnerships that are remote, time-critical and volatile. Such partnerships necessitate a new generation of collaborative project planning (PP) methodologies and services. The e-engineering Hub (URLl) is developed to offer such kind of collaborative PP services focusing on collaborative, tactical decision making that goes into the formation, work planning, contracting and trust building (TA, 2001).

eWork and eBusisness in architecture, engineering and construction

464

1.2 Business perspective Three main business drivers of the e-Hub have emerged from an analysis of the current landscape of collaborative engineering (Augenbroe, 2004): • Efficient integration of engineering services on an Ad-hoc basis into engineering projects is of strategic importance for the productivity and competitiveness of engineering design consortia. • Good project preparation and planning is a key element for the effectiveness of dispersed collaborative engineering teams thus adding to the business value and return of investment in current collabo rative engineering platforms. • The delivery of generic project planning functionality paves the way for a whole range of other services that enhance the productivity and competitiveness of companies engaged in new product development. 1.3 Technology Collaborative PP is viewed by the e-Hub as a managed process that transparently generates a set of comprehensive planning documents. They may contain both structured models and unstructured documents. The added value of the e-Hub is that the generation process is collaborative in nature and logically ordered, driven by structured content exchange. Both aspects are embodied in a formal Project Planning Model (PPM)

Figure 1. The functional architecture of the e-Hub. that companies develop and agree on at the strategic and international trade level. They represent the business intelligence of “how companies want to engage in remote

Project planning: a novel approach through a universal

465

partnerships”. The PPM is not one single model but a collection of models. Each of these models consists of a PP process model, representing with workflow (WF) models, that incorporates the coordination logic of how the project planners negotiate and reach a resolution on one of the aspects that need to be tactically agreed. Each of the WF models operates on one or more content templates. A content template is an ordered set of fields with specific meaning. The WF model controls who has read or write access to which field. All parts of the PPM are grouped in “packages”, each of which may contain a set of (sub) process models. Each process model is defined as a workflow model that adheres to the WfMC standard. In the PP platform in the e-Hub the workflow models are enacted, initiated by the project planners. Figure 1 illustrates the functional architecture of the e-Hub discussed above. The following sections present the collaborative PP process conducted on the e-Hub platform in a seismic risk analysis scenario. 2 SEISMIC ENGINEERING SCENARIO The seismic engineering scenario aims to demonstrate how a small company with a high degree of specialization, can take advantage of the e-Hub’s services. In this example, Geodeco, which is a consulting company based in Italy specialized in geotechnical, geoseismic, geo-environmental and earthquake engineering problems, provides through a Web Portal, engineering services to companies seeking advice on seismic risk assessment problems. The portal helps the potential clients to find other companies or professionals able to provide the required services. It has to be noted that the same concept could be applied to very different engineering fields. The scenario just shows one example related to the civil engineering domain. In this scenario, a Dutch design company (the Client) has won a project in Central Italy to design a Paper Mill. The project is at preliminary design stage. The company knows that the location is a strong seismic area, but it has no expertise in seismic risk assessment. It thus needs to employ professionals which are able to provide the necessary knowledge and services. However, the company does not have such contacts in Italy. It finds the eRiskZone portal to help it “procure” such services and collaborate with the professionals. 2.1 eRiskZone portal The eRiskZone (URL2) is a seismic engineering portal, run by GEODECO. The Client can take advantage of specific engineering services provided by the eRiskZone (mainly dedicated to seismic risk assessment, tools for distant co-engineering, information logistics, legal support, procurement etc (Figure 2). The eRiskZone also provides a sort of certification that all the companies offering services through it are regular members of the Chamber of Commerce, and the professionals are listed in the official professional associations.

eWork and eBusisness in architecture, engineering and construction

466

Figure 2. The Client interacts with Geodeco through the eRiskZone.

2.2 Use ofthe eRiskZoneportal in the scenario In this scenario, the following steps are made by the Client, the portal and other players: 1. The Client uses the interactive service provided by the eRiskZone to check the seismic hazard for the Paper Mill. The result shows that the factory could be prone to relevant seismic risk that needs to be assessed in detail by specialized experts. The portal suggests to the Client that a fiirther off-line seismic risk analysis carried out by human experts is necessary. The Client then decides to build a link with Geodeco through the portal to further discuss the possibility to request Geodeco to conduct the seismic risk analysis. 2. The Client and Geodeco then discuss and negotiate some essential project information through the portal. The eRiskZone plays a role to: – Set a general communication approach; – Manage data exchange between the two parties providing storage facilities, access right, information logistics, etc.;

Project planning: a novel approach through a universal

467

– Store related engineering service providers’ information; and

Figure 3. The e-Engineering Hub. – Provide an online infrastructure for distant co-engineering.

After several iterations’ negotiation, the Client intents to hire Geodeco’s services. 3. During this process, Geodeco suggests the Client to conduct geotechnical investigation at the site because the initial soil profile provided by the Client is not sufficient. The Client then selects a soil investigation subcontractor from the contractor list provided by the eRiskZone. 4. After all the project participants express their intend to further cooperation, the eRiskZone then leads them into the e-engineering Hub to collaboratively define the detailed work statements (Figure 3). From this point, they start to plan the project strategic issues on the e-Hub PP platform.

3 WORKFLOWS As illustrated in the functional architecture, generic PP workflows form the core of the eHub. These workflows codify the logic of a process that enforces collaborative project definition and planning conducted in the e-Hub platform with the involvement of all the project partners. Altogether, three workflows and related attribute templates are developed in this testbed with each representing a key phase of project planning process.

eWork and eBusisness in architecture, engineering and construction

468

It is important to note that each of the workflows require certain supporting engineering services to be implemented in, or deployed in co-existence with, the e-Hub. 3.1 Project definition and cost estimate workflow This workflow defines the process of collaborative project definition and initial project cost estimate. It extends the project participants' hand-shaking and initial project definition process conducted in the eRiskZone. Based on their previous discussion, project participants further define the project and negotiate the most important element for cooperation (i.e. the cost for service) in the e-Hub platform. According to the Client and Geodeco, this workflow includes the following activities: • Define the basic project charter and scope: the Client provides Geodeco with the essential project information. Geodeco also enquires some basic information from the Client. • Define project input requirements: the Client and Geodeco discuss what information the Client can provide to Geodeco at this stage, and what information Geodeco needs to perform the seismic analysis. • Define project output requirements: Geodeco explains to the Client what outcome it can provide to the Client at the end of the seismic analysis. The Client addresses what it is expecting from Geodeco. • Define any particular requirements including methodology, material, equipment, or other resources: in many cases, the Client has some special requirements to Geodeco such as a particular methodology of analysis, project team member, or equipment used. Both parties often need to have a special section to discuss these items. • Define project cost: finally, an initial cost estimate about the service is made based on the above project definition. If both parties cannot reach an agreement on the cost, may go back to release some of the constraints defined in the above items. In most cases, they will not be able to carry on the negotiation if they cannot reach an initial agreement on the initial project cost. Figure 4 illustrates this collaborative project definition process. A generic negotiation workflow is embedded in this workflow which allows users to negotiate each project definition item (e.g. Party A makes a proposal; Party B checks it. If the proposal is accepted, then it is saved into database. If it is rejected, Party B then explains the reason and modifies the proposal. The improved proposal is then checked by Party A. This process continues till both parties reach an agreement on each project item).

Project planning: a novel approach through a universal

469

Figure 4. Project description and cost estimate WF. Table 1 defines the attributes to be negotiated in the negotiation workflow, which are summarised from the Client and Geodeco industrial experience, and the related literature review (e.g. PMBOK, 2000).

Table 1. Attribute template for workflow 1. Item

Attributes to address

Project description

• ProjectlD • Projecttitle • Project description (e.g. nature, service required, location, etc.) • Attachments

Input requirements

• InputlD • Input items • Input description • Level of requirements • Format requirements • Date of submission

eWork and eBusisness in architecture, engineering and construction

Output requirements

470

• Deliverable ID • Deliverable items • Deliverable description • Type of service • Level of service • Options required • Date

Method/resource/ quality of the work

—

Deadline

—

Milestones

—

Yes/no

—

If yes, then (1) item, (2) description, (3) date

—

Final submission date

Particular requirements? • Ifresource, —

Manpower

—

Material

—

Machinery

—

Other particular services

• If method, then... • If quality, then... Cost estimate

• Cost system —

Fix rate

—

Lump sum item

—

Negotiated rate

• Amount • Payment approach • Liquidated damage • Quality retention amount

3.2 Project execution plan and scheduling workflow After both parties reach an agreement on the essential project definition and initial cost estimate, they, together with other partners, enter a stage to define various detailed project work statements in the e-Hub platform. These work statements address the most

Project planning: a novel approach through a universal

471

important collaborative issues for the execution of the project (e.g. project execution plan and schedule, quality plan, risk plan and change protocol). In this scenario, project execution plan and schedule is particularly important for project participants, therefore the related workflow and attribute template are fully developed and implemented. This section also briefly presents other related workflows and attribute templates which, though not being adopted and implemented in this testbed, are essential for most of the engineering outsourcing projects. To define project execution plan and schedule, a number of activities will be performed by project participants, which include: • Define activities: both parties collaboratively define all the potential activities which are necessary to perform the project. After defining the activities, the Client and Geodeco need to identify the partners who can perform the activities. Related partners could be identified either at this stage or at the hand-shaking stage. • Identify dependencies: after defining all the activities to undertake and the potential parties to perform them, all the participants will try to identify the dependencies between/among these activities. This shows there inter-relationships. Some new activities or sub-activities can be further identified if it is required. • Define duration: participants define the duration for each activity. In the end, the overall schedule should be addressed. • Specify deliverables: participants particularly specify the date for submitting deliverables. This further strengthens the definition of outputs defined in the workflow 1. Similarly they also further address the date for project inputs. • Address milestone: besides defining the inputs and outputs date, participants also address milestones in the defined project schedule. Figure 5 illustrates this workflow. Table 2 presents the document template for this workflow. 3.3 Contract negotiation workflow After defining the work statements, the Client and Geodeco (as well as other participants) enter the contract negotiation stage. The contract negotiation is conducted in two steps: negotiation of agreement, and negotiation of conditions of the contract. An agreement template is developed based on standard engineering service outsourcing contracts commonly used in the construction and manufacturing industries (D5.2). A contract negotiation workflow is then developed to facilitate the negotiation of the key contract items in the agreement template. For example, if there are four key items (i.e. no. of test samples, final service cost, liquidated damage, and governing laws) to be addressed in the agreement template, the contract negotiation workflow will guide the Client and Geodeco to negotiate these items step by step (e.g. no. of testing sample → service cost → liquidated damage → governing laws). The items finally agreed by both parties will fill into the “right place” in agreement template which is saved in the eRiskZone database in this case. A particular data transferring mechanism has been developed in this study.

eWork and eBusisness in architecture, engineering and construction

Figure 5. Project execution plan and schedule WK Table 2. Attribute template for workflow 2. Item Activities

Attributes to address IDNo.

Title Description Responsibility Pre-conditions Post-conditions Dependencies Precedent activity Successor activity Duration

Time

Deliverables/Inputs

IDno. Title Description Responsibility Date

472

Project planning: a novel approach through a universal

473

Milestones IDno. Title Description Date

Figure 6. Interaction between contract negotiation WF and eRiskZone database. There are two particular advantages of this approach: • The agreement template highlights the key contract items (which could be different for different engineering services); the enactment of the contract negotiation workflow thus guide users to negotiate these key issues.

eWork and eBusisness in architecture, engineering and construction

474

• The collaborative work statements generated through previous workflows are integrated into the agreement template, which provide a sound basis for the service outsource contract. The negotiation of the key contract items could be conducted on a generic negotiation platform (like those in workflow 1&2) embedded in the e-Hub, however, there are many legal and contractual related issues which are not easily addressed by general negotiation platform. Therefore, sophisticated contract negotiation platforms (i.e. eLEGAL contract editor URL3) are required. Although the eLEGAL contract editor was initially developed for ICT related legal issues, it provides an effective approach to representing contract clauses and addressing all the general legal and contractual issues general e-contracting, which makes it possible to be used for general engineering contract negotiation (Ren et al, 2004). In this testbed, the eLEGAL contract editor is adopted as a negotiation platform for project participants to address the key contract items and finalize the Conditions of Contract, which often involves the

Figure 7. Negotiation of Conditions of contract through the eLEGAL contract editor.

Project planning: a novel approach through a universal

475

complex contract clauses (Figure 7). A Conditions of Contract template for engineering service has been developed, which is stored in the eRiskZone database and linked with the eLEGAL contract editor through a SOAP web service. 3.4 Supporting engineering services 3.4.1 Supporting engineering servicefor Workflow 1 A typical supporting engineering service required in this workflow is the cost estimation tool. When users enter the stage to negotiate engineering service cost, they often need the support of cost estimation tools to estimate the service cost. These tools could be a simple cost breakdpwn table where users estimate each single cost iteni by their best professional guess. In this testbed, Geodeco uses a spreadsheet as the cost estimation tool. In other cases, other sophisticated tools such as ACEIT (URL4), BEST ESTIMATE (URL5) and COCOMO (URL6) are adopted. The use of these cost estimation tools (as well as other cost estimate activities) is closely integrated through e-Hub workflow. In the seismic example, Geodeco normally estimates the service cost based on a few key factors which include scope of service, methodology, data provided by the client, deliverables, time, and overhead. By defining these inputs and the related adjust parameters, the cost estimation tool (e.g. spreadsheet) will generate the initial project cost estimate. These input factors are addressed by the project definition activities in Workflow 1 step by step (e.g. project description → (a), input requirements → (c), output requirements → (d) & (e), special requirements → (b)). The outcome of each stage of the workflow will become input to the cost estimation tool. All the key input factors will be inserted into the cost estimation tool, when the workflow runs to the final stage, and therefore, the cost estimate will be generated, which will be then used for the cost negotiation between the Client and Geodeco. 3.4.2 Supporting engineering service for Wbrkflow 2 Although Workflow 2 and the related attribute template specify the process of defining project execution plan and schedule, particular engineering tools (e.g. scheduling service) are necessary for project participants to undertake the detailed task scheduling. This is because the e-Hub is not designed as a specific task scheduling tool. External project scheduling services need to be incorporated with the e-Hub engineering services (Figure 8). Some of the commonly used project scheduling tools could be adopted such as MS. Project, Primavera, Barchart, GanttProject, task scheduling whiteboard and other visualized project planning tools (e.g. project planning JAWE and JDPG). In this testbed, project planning and scheduling starts when all the potential activities to be performed have been identified by project participants in the e-Hub platform. They then enter into task scheduling, either offline or through a task scheduling platform that could be either recommended by the e-Hub or by participants. In this testbed use is made of a collaborative task scheduling platform. For this, GanttProject (URL7) is adopted as the scheduling platform due to its particular advantages such as:

eWork and eBusisness in architecture, engineering and construction

476

• GanttProject is written in java; thus it can be run in any operating system; • GanttProject is easy to use. The task scheduling process in GanttProject follow the same process defined in Workflow 2; and • GanttProject uses a XML file format to save the schedule defined, which can be exported into HTML web pages. This allows different project participants to edit the same project schedule online. For example, the Client defines its tasks and save the schedule into the eRiskZone database; Geodeco and other partners can open the schedule from the database and improve it, then save it back to the database. The scheduling activities conducted in GanttProject are integrated through e-Hub enacted workflow (e.g. define tasks, identify dependencies and define duration). Depending on the project, schedule requirement and team members, these activities could be integrated either tightly or relatively loosely. All the notes and comments made by each participant during the collaborative definition process are recorded in the scheduling file. Project participants can also communicate and negotiate the schedule through the e-Hub basic collaboration platform. Furthermore, the e-Hub also provides a project planning and scheduling whiteboard, which allows project participants to discuss any particular aspect of task schedule or of any issue of the project plan in a synchronous session through live diagrammatic communication. This is particularly useful for the projects adopting the traditional task scheduling tools such as MS. Project and Primavera which do not support online scheduling and negotiation. Through this whiteboard, the detailed task schedule negotiation is further integrated.

Project planning: a novel approach through a universal

Figure 8. Scheduling service incorporated with the e-Hub engineering services.

477

eWork and eBusisness in architecture, engineering and construction

478

3.4.3 Supporting engineering service for Workflow 3 As discussed above, the eLEGAL contract editor (with the support of eRiskZone database in this case) provides a comprehensive contract negotiation platform for the eHub. Guided by the contract negotiation workflow, the contract editor (together with the generic negotiation workflow embedded in the e-Hub) provide both offline and online contract negotiation platforms. The contract negotiation activities conducted on the contract editor are tightly integrated with e-Hub workflow. Most importantly, tight integration through linkage with generated planning documents on e-Hub. 4 CONCLUSION The development of the e-Hub is backed by multilevel knowledge and technologies such as collaboration platforms offering shared project workspaces for team building, group communication, project management methods, portal “store front” functionality for marketing, contract management, process representation, sharing and execution, knowledge capturing and sharing. These technologies, supported by available Webhosted services, form the basis of the e-Hub. They could be integrated to form a “collaboration gateway” that provides a transparent and effective collaboration approach. This paper has demonstrated these key issues through the application of the e-Hub in the seismic engineering scenario, which can be summarised as: • The advanced technologies for Internet based communication and web hosted collaborative engineering form the baseline of the core of the prototypical e-Hubs. • On top of this core, incremental layers of additional services is built in a holonomic systems sense. Each service system offers dedicated e-engineering fimctions at increasing subsystem scales: individual, collaborative group, and e-engineering team. • The e-Hub is configured by offering transparent collaboration templates to each of these systems. Its services is defined and developed for process sharing and configuration based on the process templates for effective collaboration. The e-Hub also supports necessary and adequate levels of knowledge capture and sharing, provides small and medium enterprises (SME) back-office engineering tool support and fosters trust building, contract management and marketing relationships. • The development of the e-Hub is done with open and reusable middle ware components and deployment of existing best of breed service components through a franchise model of web hosted services. The system approach to the transparent hosting of these services is based on open back end architectures of meta product and process models of e-engineering scenarios. Through this testbed, it can be observed that the e-Hub has achieved its major expected objectives: • Offer job procurement, contracting and collaborative process facilities, including handshaking, process sharing and process mediation.

Project planning: a novel approach through a universal

479

• Offer low entry barrier for SMEs to the global marketplace for the outsourcing and fulfillment of engineering subtasks. • Offer configurable e-Engineering process templates, thus harnessing proven procedures for remote collaboration. • Enable trade organizations to enforce quality in collaborative engineering through certification of procedures and standard practices. • Provide a trusted engineering gateway to SMEs. • Support new organizational development in e-collaboration.

ACKNOWLEDGEMENTS The e-Hubs project is supported by the European Commission under the IST programmed (Contract no: IST-2001–34031). The authors would like to acknowledge the financial support of the European Commission, and record their appreciation to the eHubs project partners for their contributions to Testbed 1. REFERENCES Augenbroe, G., 2004. e-HUBs: e-engineering enabled by holonomic and universal broker services (In Press). eChallenge conference, Vienna. Project Management Institute, 2000. A Guide to the project management body of knowledge (PMBOK). Project Management Institute Inc. Ren, Z., Anumba, C.J., Hassan, T.M., 2004. D5.2: Set of working e-engineering services dedicated for seismic engineering demonstrator. Q-HUBs Project Deliverable. ISTproject: (IST-2001– 34031). Ren, Z., Hassan, T.M., Anumba, C.J., Augenbroe, G. and Mangini, M. (2004). e-contracting for the e-engineering hub, a case study in the construction industry. The 5th IFIP working conference on virtual enterprises, Toulouse, France. Technical Annex-1, 2001. e-Engineering enabled by Holonomic and Universal Broker Services (eHUBs), Description of Work. ISTproject: (IST-2001–34031). URLl: http://elf.eurodyn.com:8080/edos/index.do URL2: http://www.geodeco.it/eRiskZone/eRiskZone.html URL3: http://cic.vtt.fi/projects/elegal/public.html URL4: http://www.aceit.com/ URL5: http://www.best-estimate.com/ URL6: http://sunset.usc.edu/research/COCOMOII/index.html URL7: http://ganttproject.sourceforge.net/

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

A decision support model for material supply management for the construction industry J.Perdomo & W.Thabet Department ofBuilding Construction, Virginia Tech, Blacksburg, USA R.Badinelli Department ofBusiness Information Technology, Pamplin College ofBusiness, Virginia Tech, Blacksburg, USA ABSTRACT: Decision models are ever-present in the materials management processes of industries other than construction and have proven their worth in improving productivity and profitability. This paper presents research that focused on supply chains for the electrical contracting industry. The authors applied knowledgemanagement concepts to design an integrated, effective system of decision-support tools for materials-management decisions of an electrical contractor during the construction phase of a project We developed a structured systems design of distributed, integrated decision support systems for materials management of the electrical contractor. The research derives the optimal integration of people, decision processes, decision support systems and data that are required to support efficient and effective systems for acquisition, procurement, transport, storage and allocation of material in the construction industry. This research will extend and bring to fruition previous and current research by the principal authors that has created detailed mappings of the essential decisions, decision models and data that are required to support supply-chain activities of construction contractors throughout a project life cycle.

1 INTRODUCTION There is a growing awareness in the construction industry that materials management needs to be addressed as a comprehensive integrated management activity. Materials account for approximately 50% to 60% of the cost of construction projects. More significantly, materials management typically controls 80% of a project’s schedule and 40% of the time lost on a construction project can be attributed to bad management, lack of materials when needed, poor identification of materials and inadequate storage (Stukhart, 1995). Integrated Logistics Support, the holistic approach to supply chain management over the entire life cycle of a product, has transformed manufacturing industries over the last three decades. The construction industry, facing opportunities and threats in a global marketplace for construction, is poised to embrace a similar approach to its materials management practices.

A decision support model for material supply management

481

General activities that should be considered in preparing the plan for materials include the determination of materials needed (i.e. quantity, type, sizes, color, etc.), the sources of materials, specific dates when the materials are needed, procurement, expediting, receiving, storage, usage, disposal and provisions for contingencies. Effective planning is required to keep costs to a minimum and to insure that the material is on site when needed. Poor planning of materials will increase indirect costs as-associated with delivery and use of materials. In addition, losses in productivity, delays, rehandling, and duplicate orders among other factors can be expected when there is a poor materials management system. Material management problems have a great impact on general contractors, but are more critical for specialty contractors such as electrical contractors. Based on the coauthors’ experience, the construction industry has moved toward specialty contractors in the last decade to the point where at least 80% of the work performed on a typical construction contract is done by specialty contractors. General contractors have become, for the most part, project managers. Today there are more than 25,000 specialty contractors in the United States (http://www.assoc-spec-cn.org/). The electrical contracting market, in particular, has expanded in recent years compared to the other areas of construction. Employees in the electrical contracting industry account for around 13% of the total employees in the construction industry. The nature of the electrical contracting business requires that a large volume of sales needs to be achieved in order to support the company. In the last 14 years the electrical contracting industry has tripled their volume of sales. In addition, the number of employees in electrical contracting activities increased by more than 350,000 (NECA, 2001). This trend of moving towards subcontracting parallels the trend seen in manufacturing economy that has increased the role played by original equipment manufacturers (OEM’s) that supply basic components to name-brand companies that carry out final assembly. The effects of this evolution in the construction industry also parallels the effects witnessed in the manufacturing economy over the last decade: • increased the pressure on contractors to deliver goods cheaply and on time • flexibility for the general contractor with respect to sourcing contractors • negotiating with suppliers and manufacturers • increased need for closer coordination between the specialty contractor and the general contractor Most specialty contracting companies are small companies. Therefore, these companies have to provide services efficiently and at the lowest cost possible in order for the company to remain in business. Specialty contractors need to track constantly the materials, resources and labor due to the risk that they undertake in every construction job. This tracking is useful to avoid losing material due to theft, misplacement or damage, for productivity improvement and to compare actual resource and labor usage against planned. The electrical contractor has to plan and schedule the purchasing, expediting, receiving, storage, and installation of the materials by coordinating the different parties involved (i.e. estimating, job managers and field personnel). Timely availability of materials, systems, and assemblies is vital to successfiil construction. This paper presents research that focuses on supply chains for the electrical contracting industry. The authors applied knowledge-management concepts to design a

eWork and eBusisness in architecture, engineering and construction

482

prototype for an integrated, effective system of decision-support tools for materialsmanagement decisions during the construction phase of a project. Based on previous research by two of the authors, the paper first reviews current phases of material management in the electrical contracting industry including bidding, sourcing, procurement, construction and post-construction. The paper then introduces some of the challenges that face material managers. Decisions needed to be made during all phase of material management are introduced with a focus on the decisions needed during the procurement and construction phases. A proposed decision modeling solution, based on similar models adopted by manufacturing, is presented. A decision support framework is proposed that integrate various alternatives and parameters to provide possible solution for some of the decision making questions posed. 2 CURRENT PHASES OF MATERIAL MANAGEMENT IN CONSTRUCTION Research work by Thabet and Perdomo (2003) has investigated current materials management practices in the EC industry. The investigation considered the entire range of activities necessary for procuring the needed material, starting with the estimating process and ending with site delivery, distribution and storage logistics. Research outcomes included documenting the problem bottlenecks in the supply chain as well as identifying and classifying the various criteria that influence the decision process for procuring material. A conceptual framework for the material supply chain process was developed based on various discussions and interviews with office and site personnel from the electrical contracting industry including contractors, suppliers, manufacturers and a software provider. Five distinct phases, as shown in Figure 1, that comprise the material management process were identified: 1—Bidding Phase, 2—Sourcing Phase, 3—Materials Procurement, 4—Construction Phase, 5—Post-Construction Phase. Based on information acquired from these interviews, a more detailed representation of the five material management phases for a typical electrical contractor was developed. During the Bidding Phase the contractor identifies the materials needed as well as any special requirements or special materials to be used in the project. Quantities needed are estimated and a bid package is put together and submitted. In general, materials used by electrical contractors can be classified into two categories: miscellaneous materials or commodities, and major materials. Miscellaneous materials refer to off-the-shelf items such as cables, conduits, straps and fittings. Major materials include switch gears, lighting fixtures, alarm systems and other items that need to be designed/fabricated specifically for a given job. If the project is successfully won, the contractor schedules a meeting to generate a material requisition

Figure 1. Typical material cycle in a construction project.

A decision support model for material supply management

483

schedule (e.g. release forms) specifying material types, quantities needed, dates when the material should be delivered and any additional information needed for clarification. In addition, any notes related to particular items and the drawings for the job are included. Figure 2 illustrates this phase. The Sourcing Phase involves the selection of reputable suppliers and manufacturers. The selection of suppliers is critical and the performance of a supplier can decide between a successful project and a project fiill of delays. Therefore, the contractor needs to verify that the supplier is capable of delivering the right material (i.e. type, quality and quantity) when needed (i.e. at dates specified). In general, most materials (miscellaneous and major) are purchased through suppliers/distributors. Typically, after a contract has been awarded, the contractor issues a temporary purchase order to ensure the supplier that the material will be bought from him/her upon approval of submittals. Once the submittal process is over (i.e. submittals are approved), the temporary purchase order becomes a valid contract. This phase is presented in Figure 3. The Material Procurement Phase involves the generation of a material requisition schedule. Once a

Figure 2. Bidding Phase. material requisition schedule is in place, individual requisitions are generated from the construction site by either the foreman or the project manager. Once a release form is generated, suppliers are contacted for procuring the material needed. The type of material needed, quantities, time when the material is needed and delivery location are specified to the supplier. This phase is presented in Figure 4. The Construction Phase involves receiving, storing and distributing the material on site. The receiving process involves inspection of the material when it is received to verify that the type of material delivered is the one ordered, quantities received against quantities ordered and quality of the delivered material. In addition, the contractor needs to decide where the material will be stored depending on the time that it will be used, storage limitations, and possible damage, among others. Figure 5 depicts the Construction Phase. In the Post-Construction Phase and after installation of the materials in place, the EC has to manage any surplus material. The surplus is handled differently depending on the type of material and also whether or not the contractor has a warehouse. If the company has a warehouse, the surplus material is stored in the warehouse for use in future projects. Other companies return surplus material to the supplier for reimbursement. Usually, there is no penalty or re-stocking fee for commodity items. For specialty items there is usually a 20–25% penalty. The EC has to track surplus material to avoid lost or theft.

eWork and eBusisness in architecture, engineering and construction

484

Figure 3. Sourcing Phase.

Figure 4. Material Procurement Phase.

Figure 5. Construction Phase. 3 CHALLENGES WITH CURRENT PRACTICES Currently, supply chain functions in the construction industry are often performed on a fragmented basis with minimal communication and no clearly established responsibilities between the parties involved. In addition, the collaboration required between departments has not been considered and implemented. This fragmentation creates gaps in information flow, which leads to delays in material ordering and receiving, expediting costs, excessive inventories of some items and project delays. Every phase in the SCM process is important for the successful completion of a construction project. Furthermore, the

A decision support model for material supply management

485

manager needs to realize that decisions taken at one stage in the process will certainly impact other activities and processes in the supply chain, therefore these effects are not realized due to this fragmentation. Specific problems that are encountered are: • There is no structured approach to SCM in the construction industry • Supply chain decisions are not made consistently across projects and contractors or even within a project and contractor • The construction industry does not learn from experience how to improve its supply chain methods • There is no theoretical foundation for the methods for supply chain management that are currently used in the construction industry • There are cultural characteristics of the construction industry that encourage shortsighted actions and little information sharing and cooperation, especially at the level of foremen and supervisors • There are limited IT applications and available technologies for SCM in the construction industry • Especially in small contractor companies, there is little or no awareness among personnel who carry out supply chain activities of the impacts of poor planning and decision making on the “big picture” of project costs and delays

Figure 6. Decision node for the Construction Phase. • Small contractors cannot afford to invest in research and development of new technologies and processes. • An industry made up of thousands of small contractors requires standardization

4 DECISION MAKING IN THE MATERIAL MANAGEMENT PROCESS There are a number of managerial decisions that create and regulate the supply chain. Among these decisions are from whom to buy, when to buy, how much to buy, when to deliver, where to deliver and where to store. Figure 6 illustrates a summary of decisions in every phase. The research presented in this paper concentrates on the procurement and

eWork and eBusisness in architecture, engineering and construction

486

construction phases, therefore only the decision making process performed during these faces will be explained. There are critical decisions that need to be made at the procurement and construction phases. This includes how much material to buy, when to buy this material, when to deliver, where to deliver and where to store on site. The decision of how much to buy is very important to assure that material quantities needed are available and that there are no material shortages. The decision of when to buy is important to ensure that material is available when needed. The lead times for the material to buy need to be considered. The decision of when to deliver requires understanding the progress of the work, installation rates and forecast of any possible changes in these factors. In addition, the performance of the supplier needs to be considered. The decision of where to deliver the material requires space planning and consideration of site limitations, pre-fabrication strategies, and subcontractors to be used. The decision of where to store on site requires considering the number of trades working, possible damage and any storage restrictions. Review of current practices (Thabet and Perdomo, 2003) indicates that the electrical contractor buys the material based on what the foreman requests without considering the storage costs associated with having material early on the construction site. The important aspect is purchasing and delivery of the material either to the jobsite, warehouse or subcontractor without considering any costs that could result from damage while the material is stored and/or re-handled due to space limitations. Better material management practices and more structured decision making models could increase the efficiency of the material management process. There is a growing awareness in the electrical contracting industry that materials management needs to be addressed as a comprehensive integrated management activity. Increasing pressures on project costs and completion times are motivating the need to make supply-chain decisions in a coordinated fashion and in consideration of minimizing total supply-chain cost without causing stockouts. The performance of these decisions is heavily dependent on the combination of the different alternatives listed in every phase. Currently, there is no structured approach to identifying the optimum combination of decisions that will lead to processing the needed material with the least total costs. Fortunately, model-based, computerized solutions to supply-chain problems are proliferating. However, the typical contractor may be over-whelmed by the technology embodied by these solutions and the challenges of integrating this knowledge into business practices. A definition of the data, models, decision makers and procedures that make up this knowledge and a mapping of their relation-ships and uses is a vital first step towards building integrated decision support for the contractor. The term “knowledge management” has become the recognized name for this definition and structuring of all of these “knowledge elements” that an organization uses to make decisions. 5 DECISION MODELING APPROACH The last two decades have demonstrated that implementing the use of decision support technologies in an industry can be done successfiilly only with an enabling culture change. In the manufacturing sector the movements of total quality management, just-intime management, business process re-engineering

A decision support model for material supply management

487

Figure 7. Example of a decision model. and enterprise resource planning have produced a body of theory and practice that clearly supports this claim. Like other manufacturing and service industries, the construction industry is being pressured by market forces to be more effective, more responsive, more efficient and to provide more value by reengineering its methods and processes. The economic threat posed by current practices in the construction industry strongly motivates change in this industry. Comparing the supply chain system for construction with those of other industries we can infer that the successful implementation of material management depends on the decision making process and in recognizing the interdependency between departments and the decisions made at different stages of the project life cycle. Therefore, the supply chain activities should not be studied in isolation and all the aspects that might have an impact on the system should be considered. There are a number of managerial decisions that create and regulate the supply chain and are embedded in the five-phase process for materials management that were described earlier. Our current and previous research is directed at identifying and specifying these key decision points in the supply chain process. Each of these decisions should be supported by the application of a decision model in a decision support system. A decision model is an analytical tool, usually in the form of a computer application, that assists a decision maker in estimating the outcomes of different alternatives and quantifying the tradeoffs inherent in choosing one alternative over another. Figure 7 shows schematically an example of a decision model. Fundamentally, a decision model quantitatively describes the cause-efFect relationship between two sets of causative factors and the set of evaluative measures that the decision maker uses in order to judge the desirability of each alternative. The causative factors are divided into a set of controllable factors that constitute the decision alternatives and a set of un-controllable factors called parameters that must be measured, estimated or forecasted. The evaluative measures are called performance measures because they quantify the “performance” of each decision alternative. Alternatives represent the different courses of action that a decision maker could exercise for a particular decision node or possibilities from where the decision maker chooses. Parameters represent “values” that affect the decision making process. A parameter could remain constant throughout the analysis or could be an uncontrollable variable.

eWork and eBusisness in architecture, engineering and construction

488

Uncontrollable variables refer to those parts of the decision that although having an eifect in the decision taken, is not controlled by the decision maker; its values are given by factors external to the model. An example of an uncontrollable factor could be the level of demand when deciding how much production to allocate to a new product. In reality, many parameters that affect the decision making process are variable, however they are treated as constant. This assumption is part of the simplification that characterizes decision modeling processes (Cooke and Slack, 1984). Parameters must be satisfied while selecting an alternative and are critical data to be considered in the analysis since they could have a great impact in the decision making process. Some decision models go fUrther than describing the outcomes of each alternative by determining the optimal choice from among all of the alternatives. These kinds of models are called prescriptive models and embody a search routine that a computer uses to carry out an intelligent, restricted trial-and-error search for the optimal solution. Prescriptive models leverage the decision maker by evaluating tradeoffs that are too complex or numerous for human judgment to comprehend. For example, a descriptive model could be used when a company needs to decide on how much material to order. Decision alternatives might include ordering material as estimated, order less material than estimated, order more material than estimated, order material based on actual quantity or order the quantity calculated with the EOQ model. Examples of parameters might include the storage capacity, availability of space, location of the job, discounts, progress of the work, among others. Examples of performance measures might include shortages, surplus of material, among others. Based on the information input (i.e. alternatives and the parameters), an analysis can be performed to assist the electrical contractor with the amount of material that should be acquired. 6 PROPOSED DECISION SUPPORT FRAMEWORK FOR SCM The proposed framework will encompass several decision flowcharts at different decision nodes. Decision nodes in the material management process include those points where “something” has to be done or a decision has to be made with material such as purchasing, delivery options and storage alternatives. Each flowchart will provide the logical sequence to respond to the different decision making questions presented in Figure 6. An example flowchart that comprises part of the framework is presented in Figure 8.

A decision support model for material supply management

489

Figure 8. Example decision making flowchart. The decision of what type of material to buy deals with the type of material to buy, based on requirements of the construction job, progress, schedule, productivity, among other factors, and from whom to buy the material. Materials used by electrical contractor fall into two main categories: miscellaneous material and major material. These two types of material and the material source (i.e. supplier) represent the alternatives for this decision node. The parameters for this decision node depend on the type of material being considered. Examples of parameters for major material include the brand, size, capacity and cost. One of the most important parameters for major material is the brand. Often, the brand of the material to be used in a certain project is specified in the contract documents, therefore the contractor has to buy the material from the specified source. If the brand is not specified in the contract documents, the contractor has two options to obtain material. The contractor can use a negotiated process with a manufacturer or a bidding process. For miscellaneous material the process is similar with the difference that there could be blanket orders or yearly contracts for the type of material being considered. If the brand is specified in the contract documents, the contractor verifies whether or not there is a blanket order for that material. If there is a blanket order in place, the contractor buys the material from that

eWork and eBusisness in architecture, engineering and construction

490

particular supplier. If there are no blanket orders, the contractor requests bids from different suppliers.

Figure 9. The model and its data extraction. The example presented in Figure 8 deals with the decision making process for a material specified in the plans and specifications, in this case a transformer from a particular supplier. Since the brand is specified in the documents, the contractor has to negotiate contract conditions with that particular supplier. Figure 9 depicts the setup for the implementation of the framework into a computer model. The model, per se, is a computer program as opposed to data. In a knowledge map, this program can be recognized as a file that is stored either on the decision maker’s computer or on the company’s server. The user calls the model application (1). The user selects, from a menu, the decision to be analyzed. This decision is specified as an intelligent decision (query).

A decision support model for material supply management

491

This definition allows filtering and extracting the model parameters needed for a particular decision from all the data available in the company’s database (2). The model parameters needed for the analysis are filtered and extracted from their permanent storage locations in the company’s database or other locations such as supplier servers, internet resources, etc. (3). Once extracted, these data are loaded into a temporary location for the running of the model (4). These data are all temporary data elements that exist while the model is being used for the specific user call initiated. The model calls the necessary analytical tools that utilize the temporary data elements to provide the best decision at that particular instant. These analytical tools are filtered using the intelligent query defined for the particular decision (5). Once the model runs and provides a decision support for the user (6), including performance measures and alternatives considered in the analysis, the knowledge elements stored in the temporary database are erased. 7 SPARCS—SUPPLY CHAIN PARAMETER CLASSIFICATION SYSTEM The performance of the material-procurement decisions is heavily dependent on the combination of the different alternatives listed in every phase of the materials management process and the factors or parameters that influence the selection among the different alternatives for each particular decision. These knowledge elements (i.e. parameters) can be acquired from different sources such as historical databases, the internet, and suppliers, among others. These data need to be extracted on a regular basis as decisions related to material management are ever present in a construction project. The identification of parameters is a task that requires more attention, since parameters related to different issues, such as schedule, suppliers, among others, need to be considered. The identification and extraction process for the parameters could be tedious and time consuming be-cause the decision maker could be extracting the information from unstructured records that contain vast amounts of data. In addition, important parameters that relate to different categories such as schedules, storage, cost, among others, need to be extracted and sorted. Currently, there is no structured model to categorize the parameters that need to be considered on the supply chain decision making process for the electrical contractor. The electrical contracting industry needs a structured database design that can allow decision makers to review and categorize these parameters. This categorization could facilitate the storage and classification of this parameter information for future extraction and use. As part of this research, a structured approach was defined for parameter classification. Based on the information gathered through interviews with electrical contracting industry personnel such as contractors, suppliers and manufacturers, and extensive literature reviews, a system for classifying parameters for material supply chain, specifically for the electrical contracting industry, was developed. The system is known as SPARCS, which is an acronym for Supply-chain PARameter Classification System. This system will allow decision makers to classify supply chain parameters and organize them in a structured format, thus minimizing the time required for data extraction and reducing the tediousness of the current approach.

eWork and eBusisness in architecture, engineering and construction

492

In SPARCS, decision supports systems (DSS) are described as independent systems for each decision to be made. Each DSS extracts the information needed from a data source that contains the specific data required to analyze that particular decision. The first step in the development of the system was to gather information from interviews with companies and literature review. Once the information was gathered, the decision nodes for material supply chain were identified, and the data needed (i.e. alternatives,

Figure 10. The SPARCS classification system. parameters and performance measures) for all the decision nodes were also identified. Once the data were identified, categories under which the parameters could be classified were defined for each decision. Examples of the categories include cost, schedule and storage. Categories could also contain subcategories. For example, the Cost category can be subdivided into direct and indirect cost. The parameters are then classified into the respective category and subcategory, if applicable. Each category is comprised by parameters that can directly influence that category. For example, some parameters that are included in the storage category are capacity, cost, etc. Figure 10 depicts an example of the SPARCS classification structure. This figure depicts information that is related to the Where to Deliver decision that was considered in the study. The main categories shown in the figure are Storage and Schedule. Sub-

A decision support model for material supply management

493

categories are used to further divide the Storage categories into on-site or off-site storage. The parameters are then classified into the appropriate category and subcategory. 8 FUTURE RESEARCH This article presented a research effort that established the knowledge and bases that allow re-engineering the current practices for material supply chain management for the electrical contracting industry. A framework for the design of a decision support system to assist the decision maker in the construction phase of the project was presented. The implementation of the framework will allow making better decisions on what material to buy, when to buy, where to deliver, where to store. This research didn’t consider all the phases in the supply chain management for the electrical contracting industry. However, it serves as the basis for future research in the area. This section presents research directions and issues that could be the basis for fUture research efforts. Some of these directions include: 1. Expand the Fmmework to Include Other Phases of the Material Management Process 2. Database Design and Development for the Knowledge Elements 3. Expand FSPARCS into a Knowledge Map By expanding SPARCS to be a knowledge map, it would def ine all of the knowledge elements of the decision support system including the decision variables, performance measures, formulas, optimization routines and human expert knowledge that are involved in the decisions, thus providing better information about the relationships among such elements. 4. Expand the Framework to Better Represent the ECIndustry The framework could be expanded to include other types of work such as residential, industrial, government work among others, consider bigger size companies, in terms of volume of sales per year and include companies from other geographical areas. 5. Development ofthe Framework into a Computer Program Further research can focus on the implementation of the design specified in this document in the development of a computer application of decision support system. 6. Build an Implementation Plan for the DSS This implementation plan should address the areas that could concern contractors such as computational requirements, educational requirements, monetary requirements and collaboration requirements for successful implementation. 7. Study Cultural Change Issues The construction industry is very resistant to change. Implementation of new innovative methods might be difficult in such an environment. Therefore a study of the culture encountered in construction is essential for the implementation of the decision sup-port system in a company.

eWork and eBusisness in architecture, engineering and construction

494

8. Implementation of the DSS in a company Implementation of the model in the field is essential for quantifying the accuracy of the model and to identify gray areas that need refinement and a closer analysis. 9. Incorporate Existing Tools and Technologies to the Developed Framework Existing technologies (i.e. web based methods, Pocket PCs, bar codes, RFID) could be very usefiil to effectively manage the materials management process. 10. Implementation ofthe DSS in other Construction Sectors The construction industry is moving towards fragmentation and in a typical construction project more than 80% is performed by specialty contractors. The concepts described in this article could be easily applied to other sectors to build industry specific decision support systems for material supply chain.

9 CONCLUSION An effective material management system is essential to avoid material shortages, misplacements, loss, and theft which might result in increases in crew idle times, loss of productivity and delay of activities. Electrical contractors should implement an efficient material management system due to the fact that in most of the cases they are asked to squeeze their bids in order to keep the costs of project under budget. In such a case, failures to effectively manage materials could result in decreases in profit or even a loss. The pnmary goal is to have the matenal needed, in the amounts needed, with the quahty required, and the time that they are needed. Most electrical contracting companies have a material management system that serves their needs, although it could be improved. Standardization of the material management system could be a step forward in improving the system and eliminating some of the bottlenecks. REFERENCES Cooke, S., and Slack, N., (1984), Making Management Decisions, Prentice-Hall International Inc., London. Stukhart, G., (1995), Construction Materials Management, Marcel Dekker, Inc. Thabet, W., and Perdomo, J., (2003), A Framework for an Integrated Matenal Management System, Research Report Submitted To the Electrical Contracting Foundation, Inc. Web site of the Associated Specialty Contractors (ASC), http://www.assoc-spec-cn.org/ Web site of the National Electrical Contractors Association (NECA), http://www.necanet.org/

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Modeling processes and processing product model information based on Petri Nets U.Rueppel, U.R.Meissner & S.Greb Institutefor Numerical Methods and Informatics in Civil Engineering, Technische Universitdt Darmstadt, Darmstadt, Germany ABSTRACT: Process-orientation is important for the support and the coordination of planning processes in the building and construction industry. This contribution presents an approach to support the network based planning processes in civil engineering based on a formal description of planning processes with regard to specific process-relevant product model information. The objective is to enable process modeling, process analysis and process control based on Petri Nets with individual tokens. Hereby, the process-relevant information, as a distinct subset of the total amount of product model information, is represented as individual tokens processed in the Petri Net-based process model. Based on this methodological approach the network enabled software architecture ProMiSE (Process Model in Structural Engineering) with its client and server applications is presented.

1 INTRODUCTION Planning processes in the building and construction industry differ from planning and design processes of other industry domains by specific characteristics. Generally, in Civil Engineering the processes are complex and characterized by a – high number of planning participants where each planning participant is a specialist in his technical domain and each planner has his own view on the building project, – heterogeneous and distributed planning environment concerning the software methods, models and means of communication, and – high demand of communication between the planning participants. Furthermore, in civil engineering projects architects, engineers, authorities and craftsmen design complex buildings with a unique design. The specific planning tasks and the associated communication network of planning participants vary from project to prqject. Consequently, an identical process model can hardly be applied to different building projects. That’s the reason why the application of process modeling and the processoriented view on the planning processes in the building and construction industry is neglected compared to other industry domains. Instead, webbased projectcommunication-systems became very widespread in the last years. These systems mainly base on document-management tools and therefore don’t provide appropriate means for

eWork and eBusisness in architecture, engineering and construction

496

the coordination of planning processes and the control of communication between the planning participants. Basically, these project-communication-systems don’t rely on a consistent process model at all. 2 PETRINET-BASED PROCESS MODELING IN CIVIL ENGINEERING The presented approach supports the coordination of distributed and cooperative planning processes in Civil Engineering based on the Petri Net theory. Hereby, the focus is not so much on the product modelling but rather on the process orientation, i.e., the identification, publication, analysis, optimization and finally the management of planning processes. Nevertheless, processing distinct product model information is essential for the case-based process management and control. 2.1 Formal process modeling methods From the early 60s different process modeling methods have been developed each addressing its specific objectives. However, there is one important criteria for the use of a certain modeling method, which is known as the degree of formalism. In general, nonformal, semi-formal and formal modeling methods are distinguished. In non-formal modeling methods neither the syntax nor the semantics are defined. Non-formal modeling methods are, e.g., the human speech, pseudo-code or the UML use-case diagrams. In semi-formal modeling methods, e.g., the eventdriven process chains (EPCs), entityrelationship-models (ERMs) or UML sequence diagrams certainly the syntax is clearly defined, but not the semantics. Finally, in formal modeling methods the syntax and the semantics are clearly defined. Examples are programming languages, simulation models and mathematical models. However, there exist various formal modeling methods like ACP, CSP or CCS which have an algebraic character but no appropriate graphical representation. These methods are hardly suitable for process modeling [Aalst/Hee 2002]. 2.2 Petri Nets for process modeling The Petri Nets provide both a mathematical formalism and a graphical representation based on the graph theory in order to model the concurrent and asynchronous behaviour of a discrete system. The Petri Net theory origins from the PhD thesis of Carl Adam Petri in 1962 [Petri 1962]. Since then, various researches, extensions and improvements have been applied to the original Petri Net theory. The application of Petri Nets to process modeling and workflow management has been introduced by, e.g., v.d. Aalst [Aalst 1998a] and Oberweis [Oberweis 1996]. Especially, the application of Petri Nets on civil engineering processes is explained in, e.g., [Rueppel et al. 2003]. The main reasons for modelling Civil Engineering processes with Petri Nets are – the graphical representation, – the bipartite structure with places and transitions for modelling both planning states and planning activities,

Modeling processes and processing product model information

497

– the token concept for modelling logical firing conditions and the flow of planning information within an engineering workflow, and – the mathematical formalism for structural, behavioural and simulation analysis of engineering process models. For a short introduction to Petri Nets see, e.g., [Aalst 1998a], for a comprehensive introduction, e.g., [Reisig 1985] or [Baumgarten 1990] are recommend. As illustrated in Figure 1 Petri Net consists of places, transitions and arcs, with each arc connecting either a transition and a place or a place and a transition. The tokens reside on the places. Based on well defined rules the transitions can “fire” and thus let the tokens “flow” through the net. The basic idea in modeling Structural Engineering processes with Petri Nets is to describe – planning states with places, – lanning activities with transitions, – planning dependencies with arcs and – planning information with tokens.

Figure 1. Petri Nets for modeling engineering processes. Places, transitions and arcs form finite sets. Additionally, mapping functions and firing rules assign tokens to places and thus form another set, the so called marking of the Petri Net M. The marking M denotes a discrete planning state within the whole planning process. Based on this marking M, various structural and behavioural analysis possibilities can be derived from the Petri Net. In [Aalst 1998a] a special formal property,

eWork and eBusisness in architecture, engineering and construction

498

the “soundness” property, is defined in order to test the correctness of a Petri Netbased process model. 2.3 Petri Nets with individual tokensfor process decision navigation Petri Nets with individual tokens extend the original Petri Net theory by concepts of data types and the manipulation of data values, known from programming languages. Especially, Petri Nets with individual tokens are well-suited for systems modeling communication, concurrency, synchronization and resource sharing [Jensen 1996]. Using the example of process decision navigation the application of Petri Nets with individual tokens for processing product model information in the process model is illustrated. Typically, in process models decisions are modeled as XOR-splits. In Petri Nets these XOR-splits consist of a marked place and subsequent transitions, with each transition initializing a specific process path (see Figure 2 left hand side). In “simple” Petri Nets, e.g., condition/event-nets or place/transition nets, the decision is made by a human supervisor interactively or by the system either based on a random value or a probability function. The basic drawback arising from process modeling with simple Petri Nets is that there is no reference to any product model information at all. However, product model information

Figure 2. Process decision navigation modeled as XORsplit with Petri Net elements. is essential for decision making in process decision navigations. Petri Nets with individual tokens overcome this drawback in two ways: – firstly, the tokens can carry information, e.g., distinct product model information. – secondly, the transitions can be associated with (firing) conditions evaluating the information. The right hand side of Figure 2 shows typical process decision navigation modeled as Petri Net with individual tokens. The individual token, often referred to as “coloured token”, carries the information about the “Geotechnical Category” (GC). This processrelevant information will be discussed in more detail in section 5. Figure 2 illustrates the token in grey-scaled colour representing the information about the GC and its value 3. The subsequent transitions are associated with a condition

Modeling processes and processing product model information

499

evaluating the token’s GC-value. In the presented example only one transition with GC==3 will yield true und thus initialize subsequent planning processes (path P3) based on the token value, i.e., the product model information. In this way, it is possible to process distinct product model information for process decision navigation in the process model. Of course, there are other typical process structures like process synchronization for which the use of product model information is absolutely important. 3 PROCESSING MODEL INFORMATION IN PETRINET-BASED PROCESSES MODELS According to the reference model of the Workflow Management Coalition (WfMC) specific data generated or updated by humans or technical application programs during the process run time has to be accessible for process management. In [Hollingsworth 1995] this kind of data is termed “process-relevant data” in contrast to “application data” which denotes the total set of product model information. In order to make

Figure 3. Process-relevant information linking product model and process model. the process-relevant data accessible to the process control software it has to be – abstracted from standards, regulations and engineering knowledge – represented in a computer processable form suitable for a specific process modeling technique. 3.1 Abstraction of process-relevant information A current discussion of the abstraction of processrelevant information by example of geotechnical standards and regulations is presented in [Katzenbach et al. 2004]. Generally, the abstraction of process-relevant information is based on

eWork and eBusisness in architecture, engineering and construction

500

– process modeling knowledge, – the analysis ofplanning processes, e.g., constructionoriented analysis, applicationoriented analysis or dialogue with technical engineers, and – the analysis of standards and regulations. Hereby, the amount of process-relevant data abstracted from the total set of product model information is mainly influenced by the granularity of the processes being modeled. The abstraction of appropriate process-relevant data is an import step towards the linkage of product model and process model (see Figure 3). 3.2 Representing process-relevant information as individual tokens in theprocess model The next step is to represent the process-relevant data in a computer processable form especially as individual tokens of the Petri Net-based process model (Figure 3). In general, the process-relevant information can be modelled as a list of key-value-pairs where each pair is extended by an index, with the following meaning: – the “key” provides a name of the process-relevant information, e.g., “Geotechnical Category” – the “value” provides the corresponding value, e.g.“1”, “2” of “3” – the “index” provides the history of the information. This data structure is encapsulated as individual token and thus becomes immediate part of the process model. There it can reside on the Petri Net’s places and mark the current planning state or it can be processed by the Petri Net’s transitions for example at XORsplits or AND-synchronizations. 4 IMPLEMENTATION PROMISE For the management of engineering processes in heterogeneous computer networks the network enabled software tool ProMiSE is being developed at the Institute for Numerical Methods and Informatics in Civil Engineering in close co-operation with the Institute of Geotechnics at the Darmstadt University of Technology. ProMiSE is based on Petri Nets with individual tokens to represent and evaluate process-relevant product model information. ProMiSE is used for – process design, definition and analysis at build time, and – process instantiation, control and user/software interaction at run time. From the developer’s point of view the implementation of ProMiSE is based on two concepts: – on the one hand own programming approaches have been implemented in order to realize graph theoretical algorithms, workflow specific analysis properties like, e.g., the soundness property, and network communication mechanisms.

Modeling processes and processing product model information

501

– on the other hand, existing Java Petri Net archives, like the “Platform Independent Petri Net Editor” (PIPE), have been iritegrated. PIPE provides basic Petri Net analysis possibilities, e.g., liveness, boundedness or safeness [Bloom 2003]. In ProMiSE the information representation is realized with the Petri Net Markup Language (PNML)

Figure 4. ProMiSE Architecture. [Kindler 2002]. The PNML format is the basis for the file-based input/output, the storage in XML databases or the network exchange based on WebServices. Especially, the ProMiSE interface to PIPE uses the PNML information representation with the JDOM API [Hunter/McLaughlin 2001]. The Petri Net based process control software tool ProMiSE is embedded in the JBoss application server with interfaces to the relational database system MySQL and the native XML database Xindice [Xindice 2002]. The network interaction between ProMiSE and client applications during process run time is realized with WebServices based on the Apache Axis implementation [Axis 2002] [Chappell/Jewell]. Figure 4 illustrates the ProMiSE architecture comprising the ProMiSE server and different client applications like standard internet applications, e.g., an E-mail-client, a process modeling client and technical applications, e.g., GAPP (“Geotechnical Application for Product and Process Modeling”). Concerning the process modeling client a file-based interface to the software ARIS Toolset was realized (see Figure 5). In ARIS event-driven process chains (EPCs) are the preferred process modeling technique. The EPC information can be exported as XML file in the ARIS Markup Language format (AML). The trans formation from EPCs to Petri Nets is based on the formalization introduced in [Aalst 1998b]. Hereby, special process routing blocks comprising places, transitions and arcs have to be added to the EPC process structure in order to satisfy the formal requirements of a Petri Net-based process model.

eWork and eBusisness in architecture, engineering and construction

502

Figure 5. Formal transformation from EPCs to Petri Nets.

5 PLANNING SCENARIO FROM GEOTECHNICAL ENGINEERING A typical design task in structural engineering is the design of the foundation for a building and the corresponding retaining wall for the excavation. This task is carried out by the geotechnical engineering in cooperation with other planning participants, e.g., the architect, the structural engineer or the environmental approval authority. For design purpose the geotechnical engineer has to process various information. In an early planning phase the geotechnical engineer determines the “Geotechnical Category” based on the loads of the raising building construction, the design of the foundation with the retaining wall, and the soil structure with groundwater information (see Figure 6). The “Geotechnical Category” is defined in [DIN 4020]. Once, the geotechnical engineer has determined the category, it becomes part of the soil expertise. Based on this value, different subsequent planning tasks have to be initialized. Figure 7 illustrates a part of the process model according to DIN 4020 and enlarged the process decision navigation modeled as XOR-split processing the “Geotechnical Category”value. Hereby, the transitions t12, t13 and t14 do not model real world planning activities. In fact they are automatic transitions for processing the process-relevant product model information. This product model information is immediate represented in the process model as an individual token. Depending on the token’s value only one transition yields the value true und thus initiates subsequent planning activities, e.g. the “Design of the Measuring Devices” modeled by transition t16. To specify the “Geotechnical Category” and to submit the soil expertise, e.g., as PDFdocument to the ProMiSE server, the Geotechnical Engineer can use a simple SOAP client and send the information to a specific WebService. The WebService filters the SOAP message: (a) the soil expertise document is stored in the servers file system and there it is accessible for other planning participants; (b) the processrelevant information is represented as individual token in the Petri Net-based process model and there it is processed in order to initiate specific planning activities. With regard to the ProMiSE

Modeling processes and processing product model information

503

architecture introduced in Figure 4 the network communication from the SOAP client via the Petri Net server to a specific planning participant according to the process model is illustrated in Figure 8.

Figure 6. Definition of the geotechnical category.

eWork and eBusisness in architecture, engineering and construction

Figure 7. Process decision navigation based on the geotechnical category.

504

Modeling processes and processing product model information

505

Figure 8. Network communication controlled by the Petri Net server ProMiSE. 6 CONCLUSIONS Process-orientation is an important approach for the support and the coordination of planning processes in the building and construction industry. Within this context the methodological approach based on Petri Nets with individual tokens is the basis for the distributed architecture ProMiSE. ProMiSE provides means for process modeling, process analysis and process control based on network interaction with client applications. Hereby, the process control relies on the representation of distinct processrelevant product information as individual tokens of the Petri Net-based process model. REFERENCES v.d.Aalst, W.M.P & v.Hee, K. 2002. Workflow Management, Models, Methods, and Systems, MIT Press v.d. Aalst, W.M.P 1998a., The Application of Petri-Nets to Workflow Management, In: Journal ofdrcuits, Systems and Computers, 8(1), World Scientific, Singapur, p. 21–66 v.d. Aalst, W.M.P. 1998b. Formalization and Verification of Event-driven Process Chains, In: Computing Science Reports, 98/01, Eindhoven University of Technology, Eindhoven Axis 2002. Apache Axis, The Apache Project, http://ws.apache.org/axis Baumgarten, B. 1990. Petri-Netze—Grundlagen und Anwendungen, Spektrum-AkademischerVerlag Bloom, J. 2003. Platform Independent Petri Net Editor (PIPE), Imperial College, London, Computer Department, http ://petri-net. sourceforge.net Chappell, D.A. & Jewell, T. 2002. Java Web Services, O’Reilly DIN4020. 2003. Geotechnische Untersuchungenfurbautechnische Zwecke, German DIN-Standard, Beuth-Verlag D. Hollingsworth. 1995. Workflow Management Coalition (WjMC)—The Wbrkflow Reference Model, Document Number WfMC-TC-1003, http://www.wfmc.org/ Hunter, J. & McLaughlin, B. 2000. jdom.org, http://www. jdom.org

eWork and eBusisness in architecture, engineering and construction

506

Katzenbach, R., Meissner, U.F., Rueppel, U., Savidis, S.A., Giere, J., Greb, S. & Mejstrik, M. 2004. Abstraction of Process-Relevant Information from Geotechnical Standards and Regulations, accepted for: Xth International Conference on Computing in Civil and Building Engineering (ICCCBE), 02–04 June, Weimar, Germany Jensen, K. 1996. Coloured Petri-Nets—Basic Concepts, Analysis Methods and Practical Use, Springer-Verlag Kindler, E. 2002. The Petri Net Markup Language, In: H.Weber (ed), Petri Net Technology for Communication Based Systems, Springer LNCS Oberweis, A. 1996. Modellierung und Ausfuhrung von Wbrkflows mit Petri-Netzen, TeubnerVerlag Reisig, W. 1985. Petri Nets, An Introduction, In: W.Brauer, G.Rozenberg & A.Salomaa (eds.), Monographs on Theoretical Computer Science, Springer Verlag, Berlin Petri C.A. 1962. Kommunikation mit Automaten, Schriften des Instituts ftir Instrumentelle Mathematik der Universitat Bonn, Bonn, Germany Rueppel, U.; Greb, S. & Theiss, M. 2003. Managing Distributed Planning Processes in Fire Protection Engineering based on Agent Technologies and Petri-Nets In J.Cha, R.JardimGonçalves & A. Steiger-Garçāo (eds), Proceedings ofthe 10th ISPE International Conference on Concurrent Engineering, Book 2, p. 651–656, Madeira Island, Portugal, July, 2003 Xindice (2001), Apache Native XML Database, The Apache Software Foundation, http://xml.apache.org/xindice

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

A building material information system: BMIS—in the context of CONNET-Turkey project E.Taş, L.Tanagan, H.Yaman & A.Dikbaş Istanbul Technical University, Faculty ofArchitecture, Istanbul, Turkey ABSTRACT: Building material information supply is discussed. The problems which are encountered by users on web-based building material information sources in Turkish construction sector and worldwide are evaluated. A building material information system—BMIS which is being revised for CONNET-Turkey project is introduced in brief.

1 INTRODUCTION It is a well-known fact that building material sector grows parallel to the technological developments in the construction sector since 1970s. There are many imported building materials and components available in the market besides those are being manufactured in Turkey. All of these products have an effect on construction sector as a whole complex manner. On the other hand, it is a very significant enrichment for the users who accomplish to select an appropriate building material among alternatives. The very process of getting access to choose and specify building materials is persistently changing by virtue of the emerging information technology tools. By the help of these tools, it is also easy to access up-to-date, accurate and sufficient information about building materials on time. At the moment there are numerous information sources that have a very intense and up-to-date content related to building materials in the countries where construction sector is well-developed. In the last decade in particular web-based information tools have been dramatically developed. Emerging web-based technologies offer opportunities to create a straight link among manufacturers, suppliers and customers. Online supply chains and electronic business considerably change the way products are specified, ordered, customized, marketed and sold. It reduces the time and effort spent in the assessment and choice of appropriate building materials and components. Hence, more efforts can be spent to decrease the total building cost. Simultaneously, these tools provide opportunities, – to the users to make comparisons among the alternative building materials and components available in the market faster than conventional methods, – to the manufacturers and suppliers to introduce and present comprehensively their products and to make less investment in marketing operations.

eWork and eBusisness in architecture, engineering and construction

508

Material and labor inputs used up through the construction process create quality control dilemma. That is the reason why the performance of the building materials pointed out in the catalogues cannot be accomplished after the construction has been completed. Manufacturers spend a great effort to solve the problem in the scope of total quality management. Besides, in the building materials sector numerous new products introduced to the market continuously. It is becoming unattainable to check their performance by tests, thus most of the new products are to be used without being sure if they have satisfactory performance or not. In this case, making the users to be in conscious is quite important. Users should consider following factors throughout the assessment and selection process of building materials: – the properties of the materials that are pointed out in the catalogues, – the physical, chemical or aesthetic compatibility with other materials, – costof the material, – availability of the material particularly for long-lead items, – familiarity or experience (that is to say knowledge about the material by craftsmen and suppliers), – laborcost, – labor skill, – guarantee conditions, – standards, codes, regulations, and specifications that should be satisfied, – ease of maintenance and repairs (Keyser et al. 1978).

2 BUILDING MATERIAL INFORMATION ACCESS PROBLEMS At the moment various information sources are used to choose building materials and components at different stages of a construction project. Some trade associations, institutions, public and private organizations deliver information about regulations and standards that should be satisfied in the use of building materials and components. So called information can be obtained from paper-based sources, e.g. books, journals, catalogues and brochures. On the other hand, there are online web-based sources or offline CD-ROMs making use of emerging information technology opportunities. However, users come across many difficulties to access building material information depending on technological development level they are in. Some of them are being encountered in Turkey as follows (Yaman et al. 2000): 1 The users who write technical specifications particularly in the design phase have to spend a lot of effort in finding accurate and up-to-date information about building materials available in the market, 2 Information found from different sources is not uniform. It makes hard for users to assess, compare, decide, and choose the appropriate building material among alternatives, 3 Manufacturers mostly concern in marketing, therefore their presentation includes only the best characteristics of their products,

A building material information system

509

– for marketing purposes, manufacturers sometimes need to emphasize or conceal certain physical characteristics, – the reported data they quote are obsolete or inappropriate or do not match the reporting requirements of the standardized tests, – the reported measurement units they give for the properties of the materials do not match each other. This happens especially when imported products are introduced to the market. These imported products can have either inch-pound units or inch-pound to SI unit conversions is frequently in error, – consequently, it is almost impossible to compare the alternative materials produced by different manufacturers. 4 When the performance of a building material indicated in various information sources is found acceptable, this doesn’t mean that the material is fully compatible with the other building materials or the construction methods applied. 5 The building materials found in the catalogues may not be available easily and with reasonable price within all-geographical regions of the country. 6 It is also observed that there is no effective official authority that checks up building materials both in manufacturing and using processes. This is generally the user who has to control the technical information given by the suppliers or manufacturers in order to find out if a building material is compatible to the standards and regulations or sustains its performance when applied.

3 WEB-BASED BUILDING MATERIAL INFORMATION SOURCES The subject of supplying building material information to the users has been tremendously developed by the help of the opportunities of emerging information technologies particularly within the last decade. The building material information exists mainly in paper form, e.g. brochures, catalogues etc., lost its actuality because of the development of innovative manufacturing technologies and introduction of new building materials to the market. The paper-based information rapidly is being replaced by the information, which serves the users by taking the advantage of digital media like offline CD-ROMs or online web-based databases. Such as CONNET, ROSETTA NET, SWEETS ONLINE etc. Latest developments in the communication and computer technology make available all the information or experiences in any place in the world for the users. Those can be systematically gathered, processed and used to modify the rationality of the decisions taken by the human brains. AEC communities who are the major participants of the construction sector also take advantage of webbased tools and the developments of information technology frequently They also keep up searching methods to solve their communication problems among each other such as using wireless communication. Since the quality and reliability of the information are as important as its accessibility, which has the key factor for the construction sector, it should be accessed easily and on time. Construction sector has some problems because of its nature and this has an affect on the information access issue. Some information systems serve in different domains can be a solution to the information access issue to such an extent. Building material information sources serve on the web:

eWork and eBusisness in architecture, engineering and construction

510

– provide the users making comparisons, evaluating and choosing among alternative building materials in the market in a quick and rational manner, – provide the manufacturers or suppliers publishing reliable, up-to-date and detailed technical information and introducing their new products economically, – provide suppliers developing e-commerce facilities between manufacturers and users, – provide building material manufacturers developing supply chains among each other. 3.1 Web-based building material information sources in the world At the moment there are numerous global web-based sources that supply building material information to the users. The structure of those web-based sources varies according to the (Tas et al. 1999): – financial capacity of the sponsor institutions or the organizations, – the user profile which it serves, – it’s capacity, – geographical range that it serves. On the other hand, the content of the web-based sources can be grouped under four main topics: – General information (contact info, mailing and e-mail address of the institution or organization that supports and maintains the source), – Product profile (the content contains technical and the other information about products the users look for), – Other services (catalogs, CD-ROMs and floppy diskettes, electronic magazines and manuals sent via mail or e-mail mostly on registration basis, web page design and electronic mail services), – Communication and web links (interactivity between the user and the web-based source, discussion forums, message centers, live chat, e-business etc.). Factors that influence the users’ preference of the web-based sources are: – ease of use, in other words user-friendliness and enabling accurate and fast access to information, – whether or not a well-known classification system is used in the organization of the content, e.g. CSI Master Format, CI/SfB, – having a fast search engine and a comprehensive database, – having services like technical specification data, etc., – having not only technical information but also problem solving alternatives related to the application of building materials, e.g. CAD files, – having not only online services but also using traditional tools such as mailing paperbased sources. It can be said that those services and content is progressively developed parallel to the increase of numbers of users. It is a well-organized source if the content is in order, reliable and up-to-date.

A building material information system

511

3.2 Web-based building material information sources in the Turkish construction sector According to the results of a survey carried out over different manufacturers and suppliers in different size actively work in Turkish construction sector, it is seen that manufacturers make a great deal of investment in marketing operations (Tas 2001). Most of the companies find it attractive to supply or to introduce building material information on the web because it is: – easier and faster, – integrated, – more economical than other traditional marketing methods and, – information is up-to-date, reliable. Almost all of the companies (91%) want to be involved in such a system. However, they also think that the web-based building material information supply cannot be done effectively because of the following reasons: – applications attempted on this area are still in developing phase, – there are bandwidth problems on the Internet infrastructure and, – computerization level of the users is quite low. On the other hand, the manufacturers expect that the supply of building material information via Internet will become prevailing and useful over paper-based sources within the next few years. There are limited well-organized sources in Turkey. “Building Industry Center webbased source and the building catalog off-line CD-ROM”, “Turkish Chambers of Architects’ web site”, “Turkish Chambers of Civil Engineers’ web site”, “Constructera” and “Building Guide web site” are used most frequently. When the web-based building information sources in Turkey are examined, it is seen that the efforts are not beyond collecting various brochures and scanned information files in a digital medium without using any classification system. Apart from that, some other communication facilities like e-mail bulletin and online forum are put forward by personal enforcements. Web-based contents and links are quite poor. Updating frequency of the content is quite poor as well. Hence, it can be said that web-based sources in Turkey are not user friendly or practical in use. 3.3 Problems in designing ofa web-based building information tool in Turkey Problems that should be taken into consideration in the planning phase of a web-based building material information tool are (Yaman et al. 2000): – changing inflation rate, – economical instability and diminishing of the construction sector, – omplexity of classification systems, – quality and standardization problems of building materials and components.

eWork and eBusisness in architecture, engineering and construction

512

Economical instability and changing inflation rate in Turkey are the most important factors that prevent the development of Turkish construction sector for years. It is well-known fact that the Turkish construction sector as the driving force of the economy has not only been extensively affected by the reformist economical movements but also has seen as a solution to unemployment problem. The companies, which have an active role in construction sector, are adversely affected by the cost variations during the construction process, which cannot be foreseen in the design phase. The share of the building material cost is very high in total building cost. Since it is necessary to access up-to-date market prices besides technical information of building materials. There is no widespread use of well-known international classification systems in Turkey except CI/SfB to some extent. Selection of a classification system is a very important step in the design of a building material information tool. Moreover, it is hard to exchange data among accessible information sources. The audit to check the conformity of the standards, manufacturing, storage and application of building materials and components is not enough. On the other hand, there is no well-developed quality assurance system for the imported products to control the suitability of them for the Turkish conditions. Users are not supplied with any further knowledge that can guide them through building material assessment and selection process. Most of the users are not aware enough about standards and regulations. So, building materials are mostly selected in an empirical way, such as along with personal experiences, knowledge and preferences. There are low quality mostly imported products available in market cheaper than the others. A web-based building material information tool should have a role to orient the building material sector by encouraging the manufacturers to produce high quality products and by helping users to aware in assessing and choosing building materials in Turkey. 4 A BUILDING MATERIAL INFORMATION SYSTEM MODEL (BMIS) FORTURKEY This section mentions about a research project carried out in “The Center of Building Cost and Construction Management Center” in the Faculty of Architecture at Istanbul Technical University (ITU). The main theme of the project was developing a “Building Materials Information System (BMIS)” based on relational database structure in the context of Turkish construction sector. The main objectives were to examine Turkish market and to develop an information system. It would be possible to estimate the approximate total building cost of a project even in the design development phase by means of developed information system. The information system would be used both in schematic design and design development phases of the construction process. There were two main objectives of the studies carried out within the scope of the BMIS research. First group of the objectives were as follows: – gathering all the information on the subject of building materials used in market at present, – having access to detailed technical information about available building materials in the market,

A building material information system

513

– having access to detailed information about manufacturers and suppliers, – obtaining information about the current unit prices of building materials, including labor and equipment, – choosing among alternative building materials by the taking advantage of the comparative building material data sheets, – linking the BMIS building product classification system to Turkish Ministry of Public works and Resettlement classification system, – linking the BMIS building product classification system to well-known international classification systems e.g. CI/SfB and CSI Master Format, – developing and maintaining an up-to-date building materials and components database, – making BMIS a web-based information source for Turkish construction sector operating on registration basis. The second and ultimate objective of the research project was to estimate total building cost based on fimctional building elements. The cost estimation module based on functional elements is a computer-based model that estimates the building cost in schematic design and design development phases by making use of the data retrieved from similar projects. The major steps of the research project were: – studying state-of-the-art of building material information sources accessible in Turkey and worldwide, – gathering information concerning building materials and components available in Turkish market, – developing BMIS product classification system and linking it to international and domestic ones, – developing relational database, – developing building cost estimation module, – making BMIS as a web-based information source. 4.1 Gathering the building material information From the studies of the previous research it is seen that most of the available worldwide building material information sources utilize technical specifications e.g. Spec-Data and Manu-Spec created by the manufacturers (in USA under the licensure of CSI) in order to supply the users. Conversely, the users and researchers do not have any occasion to get such wellorganized and comprehensive product literature information from the manufacturers. However, since the building materials available in the market have to hold Turkish Standard approval given by Turkish Institution of Standards (TSE), these standards were taken into consideration all through the research project. Building material standards that are currently approved by TSE were studied and material data sheets that summarize the performance characteristics like physical, mechanical, and environmental properties of the material were generated. Standardization is based on a technical and scientific institution. It determines the qualities of a material, a product, a method or a service by the rules it put forward. In the developed countries there is no obligation in the applications of standardization except

eWork and eBusisness in architecture, engineering and construction

514

the subjects directly related with the human life, health and safety. On the other hand, in developing countries, since the economical and social conditions are not at the sufficient enough, national standards have a compulsory character by the laws. The standards approved by the TSE are called as “Turkish Standard”. According to the National Notification #82/1–13 related to “Public Procurement” of Turkish Ministry of Industry and Technology it is pointed out that (Esen 1984): – Turkish standards should be referred in technical specifications prepared for public procurement and tenders, – If a Turkish standard is available in an issue, “Turkish Standard Conformity Certification” given by TSE should be looked for, – If a Turkish standard is not available in an issue, once more and only “TSEK Certification” given by TSE should be looked for, – The authority given to the other boards by regulation, law and decrees is reserved. Therefore when the users know that the building material complies with the TSE standards, they can easily assess and select it. It also helps them to be protected from deceiving advertisements or announcements. The building material data sheets that are engaged in different generic categories are developed as follows: For instance, in developing a building material data sheet in the category of “paint”, TS 7847 (Wall-Coating Emulsions for Exteriors—Polymer Based), TS 39 (PaintsOrganic Solvent Based-Top) and TS 5808 (Water-Based Emulsion Type—Architectural Paints) are analyzed. The structure of the data sheets mainly consists of following titles: – material category name, – structure of the material, – TSEnumber, – physical, chemical, mechanical performance characteristics and environmental properties of the material, – manufacturer, – the Turkish Ministry of Public Works and Resettlement classification number and unit price of material. Hence, the user has an opportunity to check the performance characteristics of the building material he/she selects from the data in the sheets, which are generated from its corresponding standards. Developing standard building material data sheet formats for Turkish construction sector and using them extensively are considered to be the next step for the research. 4.2 BMIS coding system development The system can also be used as a computer-based model that estimates the building cost in schematic design and design development phases. In that context, a BMIS coding system based on “classification system based on functional building elements” was developed. So called BMIS classification system was linked to Turkish Ministry of Public Works and Resettlement and CI/SfB classification system.

A building material information system

515

4.3 Building material information system (BMIS) development Microsoft Access relational database management system software was used to generate data entry and query forms using data structures on building material data sheets. Building material alternatives in the database were classified in the context of first group of objectives of the research project. Therefore, users could easily take advantage of cost estimation module for the current market prices of the building material alternatives as well as technical information forms. 5 CONNET PROJECT The CONNET initiative provides an open arena through which appropriate information resources can be identified within a nation and across Europe. CONNET has been developed through EC fiinding to become an open portal to connect industry practitioners to relevant information. CONNET establishes a technology transfer network for those involved with the built environment with active notification services (CONNET 2004). CONNET-Turkey project is aimed to develop a virtual technological park. However, as a candidate country, such a virtual technological park could not be designed separately projects being carried out EU 5th and 6th frame programs. Thus, CONNET-Turkey project will be linked to the backbone of the European Construction Network. Objective of the CONNET-Turkey project are: – developing a web-based virtual technology park, – preparing an infrastructure in order to integrate and to standardize Turkish construction sector consistent with EU norms, – starting up vital services for the sector. The European CONNET entry point provides a range of technology park services as well as industry-specific services such as: – management of security services, – help desk for potential service providers and for problem resolution, – information broker role, – technology observatory service, – provision of user profiles, – multi-classification support, – inter-service communication services, – multi-language supports (Bloomfield et al. 2001). Outputs of above mentioned BMIS research will be a part of the CONNET-Turkey project. BMIS will serve as an online building material and component information source. Currently BMIS is being revised for CONNET-Turkey project as a whole.

eWork and eBusisness in architecture, engineering and construction

516

6 CONCLUSION Construction sector is called as the driving force of the national economy and cannot be separated from the development process of a country. In addition, construction sector uses the products or services of the other sectors, and the products it produces also are used by the others. Construction sector is not only affected by the activities occur in the other sectors, but also affects other sectors concerning to the decisions taken and the industrial improvements. Besides, it creates employment opportunities. Alternatively, as a candidate country for the EU, Turkey knows his duties and responsibilities very well. International contractors and building material manufacturers perceive Turkey as an important potential market. Turkish contractors, building material manufacturers and designers are also getting projects abroad together with their partners. As BMIS is started being used practically, the characteristics and properties of the building materials manufactured in Turkey will be introduced to the world and it will be an important step to a web-based source which has a link with the international classification systems. Availability of the building material information on the web will give the users the opportunity of easy access to up-to-date and accurate technical information. It will have encouraging contributions to the building material assessment and selection process regarding time and cost issues. By the help of the BMIS, users can select the appropriate products bearing in mind detailed technical information and unit cost, and through user’s experiences or feedbacks. It will encourage manufacturers to search more economical production and marketing operations. The users will be aware of quality and standard issues. In addition, during the schematic design or design development phases of the project, building cost estimation can be made to check whether the building material selected is a rational choice or not. REFERENCES Building Industry Center, YEM, http://www.yapi-tr.com./ Bloomfield, D., Amor, R. and Groosman, M., 2001, “The Evolving CONNET Gateway to European Construction resources”, Proceedings of the CIB W102 conference, Melbourne, Australia, 26–27 March. CONNET Project, http://www.connet.org/ web site (2004). Esen, D., “Documenting and Studies inTurkey”, Unpublished MasterThesis, ITU Science & Technology Institute, 1984. Tas, E., Tanacan, L., Yaman, H., (1999) “Building Material Information Systems On The World Wide Web”, Proc. Int. Conference On Systems Research, Informatics and Cybernetics, Special Focus Symposium World Wide Web as Framework for Collaboration, pp: 147–156, BadenBaden, Germany. Tas, E., (2001) “A Research Project to Design A building Materials Information System”, YAPI, No.238, pp: 84–91, Istanbul, In Turkish. Yaman, H., Tas, E., Tanacan, L., (2000) “The Content of an Ideal Web Site for Building Materials Information in the World Wide Web: A Turkish Perspective”, CIB W78 Proc. Construction Information Technology CIT 2000, pp: 1069–1079, Rejkjavik–Iceland.

Ontologies

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 0415359384

Managing changes in the AEC industry—how can ontologies help? Q.Y.Cai & F.F.Ng Department of Real Estate & Construction, the University of Hong Kong, Hong Kong ABSTRACT: Due to the uncertainties and dynamic nature of the business processes in the AEC industry, a demand in effective change management has been increased. During a project lifecycle, stakeholders are highly interdependent for managing information, resources and tasks. In this collaboration process, different people may have different perspectives and personal needs to cope with the changes. For example, a change in design may impact the contractor to revise the construction process, or impact the material supplier to provide different products. Current Internet-based project management systems are unable to support this custom-tailored service and interpret the implications of changes in terms of time and cost. This paper describes an ongoing research to develop an ontology-driven change management model in the AEC industry. To support different perspectives and personal needs on the changes, ontologies are supposed to act as the backbone and enable different applications of different professions to work together in order to fulfill the desired goals. In this paper, a framework consisted of ontologies, intelligent agents and customized interface is proposed to implement the change identification and propagation. An example of ontologies is also developed to demonstrate how ontologies can help to manage information changes in the AEC industry.

1 INTRODUCTION Due to the fragmented nature of the AEC industry, various research works have been conducted in the area of information management based on the concept of interoperability, e.g., the Industrial Foundation Classes (IFC)1 and aecXML2 developed by International Alliance for Interoperability (IAI), and the method of Business Process Reengineering (BPR), etc. With the support of Information Technology (IT), information generated in the process can now be integrated and subsequently reusable across disparate disciplines throughout the project lifecycle. One example is the development of Internet-based project management system, which aims to integrate heterogeneous systems using workflow technologies and business-to-business integration standards. However, information management is not just about managing the information flow. One problem of the project management systems is the lack of flexibility to handle dynamic information changes. They are reactive, instead of proactive, to the changes

Managing changes in the AEC industry

519

initiated in other disciplines. Moreover, they treat changes as new coming messages and broadcast them to all the stakeholders. Therefore, information neglect due to information overload always occurs, and no implications of the changes are suggested for the stakeholders. As stakeholders have different perspectives and requirements to cope with changes, they need to know how to identify the changes as early as possible, how to respond to them immediately, who and what task will be affected by them, when the project will finally finished, and what the final cost will be. Therefore, possible delay, extra cost and even disputes can be avoided or minimized in the project. Based on these demands, this paper describes an ongoing research to develop an ontology-driven change management model in the AEC industry. Its initiative is to use ontologies as the backbone to support the identification of complex information interactions during the project process. In order to enable the change propagation across different domains, this research uses intelligent agents to interact with the ontological data, and also uses customized interface to deliver the custom-tailored change reports to the stakeholders. 2 BACKGROUND 2.1 Ontology as a common vocabulary to describe domain knowledge Ontology is a term borrowed from the field of philosophy, where it refers to what the world exists and how it is configured. In the Artificial Intelligence (AI) 1 2

http://www.iai-ev.de/spezifikation/IFC2x/index.htm http://www.iai-na.org/aecxml/mission.php

domain, it is defined as “a formal, explicit specification of a shared conceptualization” (Gruber 1993, cited in Fensel 2003). Here a “conceptualization” refers to “an abstract model of some phenomenon in the world which identifies the concept related to the phenomenon.” For example, when we say a “hippo”, in our minds, we can picture what a hippo looks like in the real world, and we can make sure that we refer to the same kind of animal. By this means, people from different perspectives can reach consensus through commitment to that ontology. A set of common ontologies can be used to model certain knowledge in different domains of discourse, thus people involved can speak the same language without necessarily sharing a global knowledge base. By this means, knowledge can become reusable across different domains without the point-to-point translation between pairs of applications. Based on the above characteristics of ontologies, they are widely used in the collaborative works, where different professionals need to interact with each other to achieve a cornmon goal.

eWork and eBusisness in architecture, engineering and construction

520

2.2 The role of ontologies in the AEC industry During the construction process, heterogeneous information is produced in different domains by different professionals, e.g. architect, structural engineer, contractor, quantity surveyor, E & M engineer, etc. They have different requirements and perspectives to handle the information. Therefore, it is common to see information is misinterpreted or lost in the downstream process. This is because current IT supports information exchanged in standard formats, but with little or no semantic interpretation. For example, with the development of IFC, now different CAD systems can reuse the building product models if they are IFC compatible. However, professionals still interpret the drawings from their own points of view, and sometimes this results in conflicts. If we view all the documents generated in the communication process are shared representations, then they only reflect the individual understandings. How to facilitate a shared understanding among different professionals has aroused much research awareness in the AEC industry. Ontologies are supposed to benefit this communication process by embedding domain knowledge into the common representations or agents (human or artificial) to enable a shared understanding. The development in knowledge management and intelligent agents are trying to create computing tools capable for semantic interpretation of information in a rational manner. 2.3 Existing ontologies in the AEC industry As stated above, the AEC industry needs a common terminology to structure the information in a computer interpretable manner. Over the past few years, sets of classifications/taxonomies have been developed by various organizations. For example, the IFC developed by IAI, and the IFD (International Framework for Dictionaries) developed by ISO TC59/SC13/WG6. The former develops the EXPRESS language and the schema EXPRESS-G based on the object-oriented modeling language to describe the building entities and their relationships. It is endorsed by ISO TC184/SC4 as ISO PAS 16739 in November 2002. It has achieved quite a success and popularity that now it has been adopted by many new developed visual design tools. The latter develops a framework for object-oriented information exchange. It is an EXPRESS model standardized in ISO/DIS 12006–3. Several countries have started building dictionaries based on IFD. For example, BARB in Norway, SDC in France, and LexiCon in Netherlands etc. They define the ontology “dictionary” including wall, floor, brick, bridge deck, etc. in the AEC industry. With this, they aim to keep consistency in naming and usage of the terms and their properties in software applications. IFC and IFD are currently being harmonized through the work of XM-7. The taxonomies existing in the AEC industry can be regarded as highly structured ontologies. We argue that ontologies are more than that. However, at current preliminary stage, the ontologies that we developed are based on them.

Managing changes in the AEC industry

521

2.4 Intelligent agents After the introduction of the background of ontologies, we would like to introduce the intelligent agents before we propose the framework of information change management. An intelligent agent is defined as “an autonomous, (preferably) intelligent, collaborative, adaptive computational entity. Here, intelligence is the ability to infer and execute needed actions, and seek and incorporate relevant information, given certain goals.”3 As stated in the definition, the key features of intelligent agents include: autonomy, where agent can formulate its own goals and act to meet the client’s requirements; co-operation, where multiple agents can co-ordinate with each other to fulfill the desired tasks; learning, where agents can learn as they react/interact with external environment. Having above features, agents are widely used in workflow management, business process reengineering, information retrieval and management, e-commerce, personal digital assistants, etc. These software agents operate on some standard platforms, such as XML (Extensible Markup Language), CORBA (Common Object Request Broker Architecture), Java, etc, and they communicate with each other in some common languages, e.g. KQML (Knowledge Query and Manipulation Language), 3

http://www-2.cs.cmu.cdu/~softagents/intro.htm

ACL (Agent Communication Language), IIOP (Internet Inter-ORB Protocol), XMLbased scripting language, etc. 3 THE FRAMEWORK OF INFORMATION CHANGE MANAGEMENT After reviewing the necessary background, here we propose the framework of information change management. We argue that in future Internet-based project management systems, different stakeholders will have their own agents on behalf of them to exchange information and update the changes. The agent will have the ontology as its backbone, and customized workspace as its representation interface. We illustrate this idea as below: As figure 1 shows, the framework is consisted of three layers, i.e. interface layer, application layer and theory core layer. We discuss them in more details: – Ontology (Theory core layer) This layer is the backbone for other layers. It defines a common vocabulary for different agents to communicate with each other, and supports the users to customize their interfaces based on their preferences. In this layer, terms are defined and used consistently in naming objects, e.g. task, pre-condition, postcondition, etc. This is the requisite for an explicit representation of a shared understanding of different domains.

eWork and eBusisness in architecture, engineering and construction

522

– Information Agents (Application layer) During the construction process, the Information Agents create/collect ontologies for their masters

Figure 1. Proposed framework for intelligent change management. from the project resources, i.e. documents, drawings, mail, etc. They group the planed process into the Plan Library, and query/answer the particular requests from the Task Agents. This process can be automatically or semi-automatically with the support of current/developing technologies. – Plan Library (Application layer) This is the library of the workflow engine, where the process templates are collected and stored by the Information Agents. In this library, tasks are decomposed according to the planed process. There are some constraints in order to execute the tasks, i.e., preceding tasks must be completed, the pre-conditions must be fiilfilled and the post-conditions will be achieved upon task completion. Moreover, the responsible parties, the time/schedule and the cost that associate with the tasks are presented in this library. When there are new changes occur,

Managing changes in the AEC industry

523

this library has all the planed time, cost and process templates for Information Agents to extract the related information. – Organization Sever (Application layer) This server allows the Information Agents to collect information across the organization boundaries, and stores the plan library specific to that organization, where the Interface Agents can be designed to fit for specific purpose. – Task Agents (Application layer) If we classify the Information Agents as internal agents for specific organizations to structure information for them, then the Task Agents are external ones for different organizations to exchange information and negotiate with each other in case of conflicts. Because changes are initiated by one organization, and then propagated to other ones, we need this kind of agents to roam from one organization to another to collect the updated information, and report the changes to stakeholders. – Interface Agents (Interface layer) Interface Agents represent the users to respond to the Task Agents, and facilitate the results to be displayed in a way that satisfies the users’ preferences. For example, users can choose the preference as “manual input” or “selection” to display the options. – Customized Workspace: Internet-based System (Interface layer) After the manipulation of Interface Agents, different users can have their own customized Web pages, and this is integrated into the Internet-based project management systems. With the implementation of the framework, changes are supposed to be delivered to the right hand at the right time, thus possible delay due to information neglect can be avoided, fast reaction can be initiated, and efficient authorization process can be enabled.

Figure 2. Example of ontologies related to change of space.

eWork and eBusisness in architecture, engineering and construction

524

4 ONTOLOGICAL ENGINEERING FOR MODELING INFORMATION CHANGES After setting up a framework of information change management, we developed some preliminary ontolo gies to investigate how to model the information changes to enable intelligent agents to make use of. We use the following example for ontological engineering, and use Protégé 2000 to implement it. 4.1 Modeling example During construction, the architect receives a client’s requirement to change the size of a conference room. To implement the client’s requirement, the architect relocates one of the partition walls of the conference room. The wall is between the conference room and the adjacent multipurpose function room. Hence the change implemented is just a relocation of a partition wall. However, the impacts of this change result in the change of two rooms’ space in the architecture domain, the change of air-conditioning design in the HVAC domain, and the change of structural design in the structural analysis domain, etc. The impact on the construction process depends on the current states of construction. If that partition wall has been constructed, it means a demolition of the wall is required. That means extra time and cost. If not, it means a slight modification to the construction program. 4.2 Modeling tool—Protégé 2000 To develop ontologies, several ontology editor software can be chose, such as Protégé 20004, Ontolingua, 4

http://protege.stanford.edu/index.html

WebOnto, OntoEdit, etc. In this paper, we use Protégé 2000, a graphical tool for ontology editing and knowledge acquisition with new and evolving Semantic Web language, i.e. OWL and ezOWL plugin. Comparing with other software, Protégé 2000 can interoperate with other ontology development platforms and support for most of the activities of ontology lifecycle (Corcho et al., 2002). It concentrates on the concept models instead of the syntax of the languages to be used on the web. One of the advantages of Protege 2000 is translating a model from one language to another is as easy as selecting a “save as…” item from a menu. Another key feature of Protégé 2000 is it allows the user to define the meta-class and metaslots to fit for the personal needs of concept modeling. For more technical information, please refer to its website. 4.3 Implementation In our research, we make use of IFC 2×2 to develop ontologies. In IFC, there are welldeveloped entities and relationships. According to the example mentioned above, the entity, IfcSpaceProgram, is used to define “the client requirements for the space before the building is designed. Space programs can change over the life cycle of a building,

Managing changes in the AEC industry

525

after the building is occupied. Changes to space programs take place in the facilities management/operations phase of the building life cycle.”5 Based on this, we model some key concepts and their relationships shown as figure 2. In this model, objects/entities are represented as classes with the properties/attributes as slots, and 5

http://www.iai-ev.de/spezifikation/IFC2x/index.htm

Figure 3. Example of ontology specification related to change of space. there are forms to enable capturing realistic knowledge as instances. After all the needed ontologies are finished, users can query the knowledge model to get the desired information. These taxonomies can be exported as OWL format specifications shown as figure 3. As ontology development is an iterative process, our research is still at its preliminary stage. However, we demonstrate the possibility to develop ontologies in different domains, which can be linked by relationships across domain boundaries. For example, entity IfcRelSpaceBoundary is linked to entity IfcElement by the

eWork and eBusisness in architecture, engineering and construction

526

RelatedBuildingElement relationship. The former belongs to the architecture domain, and the latter can be linked to the structural analysis domain. With different ontologies developed in different domains, we can enable different agents to embed this knowledge as their backbones to communicate with each other. 5 DISCUSSION AND RELATED WORKS As discussed above, we aim to develop some ontologies to enable agents to identify changes, and propagate them to the stakeholders in a custom-tailored way. Existing research works to reflect the impact of changes may be the use of Excel spreadsheet to automatically update the affected data, e.g. Barron and Fischer (2001). They use tables as the schema to capture the implications of changes. For example, the column may state the business process, and the rows may state resource, actor, cost, duration time, output documents, etc. Different tables can be linked together to interpret the implications. It is a very powerfiil way to reflect the impact of changes. Moreover, some researchers, e.g. Schevers (2004) use UML to develop Model Objects and Behaviour Objects to model the change propagation by using the “invokes” relation. “When the first Behaviour Object is invoked, it may change the property value, invoking another Behaviour Object. Subsequently, it could result in a chain of reactions.” (p.85) This research uses a similar concept in modeling the ontologies and their relationships, and also in an attempt to model the design change propagation. However, is there any theory behind the use of spreadsheet to model the process and manage the changes? Or is there any better way for information change management? We argue that what the spreadsheet represents is a preliminary ontology. Ontologies may have different layers/levels, which correspond to different granularities of conceptualization. Under this assumption, we are doing a research to explore the usage of ontologies in modeling the information changes in the project process. With this, we hope to find out the structure of ontologies, and explore how they can be integrated into existing applications in the AEC industry, e.g. CAD system, plan and scheduling program, cost estimation program, etc. These developed ontologies will be able to benefit the interaction between the ontological data and the applications. By this means, an effective information management is not so far away according the stakeholders’ demands. 6 CONCLUSION Due to the fact that various uncertainties, complexity of task and mobility of people involved in the construction process, changes are inevitable. In this paper, we try to illustrate how ontologies can help to manage the changes in the AEC industry. We argue that in the future, different stakeholders will have their own agents on behalf of them, which can identify the latest changes, evaluate their impacts and give customized reports to advise the stakeholders how to cope with the changes. Ontologies are expected to act as the backbone to support this.

Managing changes in the AEC industry

527

REFERENCES Barron, A and Fischer, M. (2001) Potential Benefits of Internet-Based Project Control Systems—A Study On Change Order Processing, CIFE Technical Report #126, Stanford University, http://www.stanford.edu/group/CIFE/Publications/index.html [April, 2004] Corcho, O., Fernandez-Lopez, M., Comez-Perez, A. and Vicente, O. (2002) “WebODE: An Integrated Workbench for Ontology Representation, Reasoning, and Exchange”, Proceedings of 13th European Knowledge Acquisition Workshop: Knowledge Engineering and Knowledge Management: Ontologies and the Semantic Web, Editors: Gomez-Perez, A. and Benjamins, V.R., Siguenza, Spain, pp. 138–153. Fensel, D. (2003) Semantic Web Services: A Communication Infrastructure for eWork and eCommerce, In: Lovelle, J.M.C. et al (Eds), Web Engineering: International Conference, ICWE2003, July 14–18, 2003, Oviedo, Spain, Springer, 1–7. Schevers, H. (2004) Demand Support By Virtual Experts—Supporting the Client During the Inception Phase of a Building and Construction Project, unpublished PhD thesis, Faculty of Civil Engineering, Delft University of Technology, Netherlands.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

An ontology-driven approach for monitoring collaborative design knowledge Y-C.Lai & M.Carlsen Dept of Building Technology & Structural Engineering, Aalborg University, Aalborg, Denmark ABSTRACT: Meeting minutes has been confined as recorded summaries corresponding to the discussion content of a progress meeting. The recorded summaries are sometimes used as agenda for the next meeting. The conventional approach implemented to arrange the summaries in treestructure format results in design rationales and decision intents are implicitly contained as paragraphs of weakly structured plain-text. The conventional meeting minutes are also incapable of integrating pieces of design information effectively. This paper hypothesizes that semantically structured meeting minutes may serve as dynamic medium to record key design information by presenting the design intents explicitly. This paper describes a prototype system that is developed based on semantic web technologies and ontological approach. The prototype supports design progress meeting by generating dynamic records with respect to the content of discussion.

1 INTRODUCTION The building industry has become aware that an ergonomic fit project information management system is one of the fundamental needs at the project outset so that knowledge corresponds to the activities conducted throughout the project life can be managed effectively. The project information management system has evolved from the conventional paper-based mechanism to the nowadays digital based mechanism. However, the implementation of the digital based project information system does not respond perfectly to the demands of the building industry yet indicated weaknesses identified from the current web technologies. This paper presents a hypothetical knowledge management system supported by the semantic web in which ontological approach is applied for knowledge modeling purposes. The outlines of this paper is divided into two parts where the current practice of project information management will be analyzed followed by a comprehensive description of the hypothetical system that is to improve the pitfalls identified from the current practice. 1.1 Background The design process of the building industry was characterized as a sequential conversion flow that transforms information from technical standards, legislations and other design

An ontology-driven approach for monitoring collaborative

529

specialties into solutions and product specifications. The conventional design process as such is typically disciplinary orientated, which means that different team actors concern mainly about their respective interests and knowledge to formulate technical solutions corresponding to the design requirements under their disciplinary specialties. Reworks in designs are the consequences of this fragmented design process in order to maintain the coherence among the numerous decisions made throughout particularly the ambiguous and frequently changed briefing and early design process (Mesquita, 2002). Close collaboration amongst the multidisciplinary team actors has therefore become a necessity from the outset of a project. 2 COLLABORATION THROUGH KNOWLEDGE MANAGEMENT The characteristic of building project is unique in a way to involve multi-participants from different business natures to collaborate closely throughout the project life. It has been custom for the building industry to organize a vast amount of information, particularly those generated during the early design phase, with particular mechanisms to ensure future reuse and retrieval. Basically, information that can lead to effective action can be defined as explicit knowledge (Davies, Fensel & Van Harmelen, 2003). Both the tacit and explicit knowledge have been recognized as the important strategic resource of an organization (Nonaka & Takeuchi, 1995). These two types of knowledge are reused and shared amongst the project team actors as a means to achieve the optimum state of collaboration. Organizing both of these two types of knowledge has also been realized as an uneasy task (Fruchter, 2002). 2.1 The attempts The basic need of an ergonomic fit project information management system is to enable support of traditional project management tasks in planning, monitoring, reporting and control of baseline scope, cost, time and quality (Archer et al., 1997). Such a system is also expected incorporate to the mechanisms of trend forecasting and change control, and able to manage documents in a manner that would track issues, provide fast retrieval of relevant documents and support the time limited process for the resolution of disputes (Archer et al., 1997). Several attempts have been conducted including the concept of project web, which tends to apply the fast developing information communication technologies (ICT) to manage the existing information base more effectively. A comprehensive discussion in regard to project web associated with the technology behind will be given in the following section of the paper. 3 METADATA AND PROJECT WEB 3.1 What is metadata In brief, metadata is defined as data about data, and obviously metadata itself is also data. Metadata can be embedded in the document that it describes/represents, or exist

eWork and eBusisness in architecture, engineering and construction

530

separately from the document. Metadata can be used to describe any object in the universe. Generally, metadata about an object is structured to provide a description. The structure is common for all instances of the same type of object. A very typical example for this is the library card system where each library card contains description of a book such as title, author, keywords, publishing date, and so forth (NAEH, 2004b). Metadata used in the library card system is to facilitate the library user for books searching by considering a book as an object, having a number of properties that can be represented with descriptive metadata. With this respect, it has been obvious that the application of metadata has its long history in the aspect of information management. 3.2 Project web Project web is a project-level mechanism, which is to fimction as a centralised repository for project team actors to exchange project information during the phases of planning, design, construction and facility management (FM). Digitalised information, such as design drawings, progress reports and meeting minutes are available in this information container. 3.3 Use of metadata in the building industry Integrating information, as a mechanism to improve the efficiency of information monitoring, becomes a crucial task for the A/E/C professionals. The mass amount of information produced at the project outset may have a big variety of formats, including the well structured data stored in database management system (DBMS), the semistructured HTML and/or XML files, and also the weakly structured texts/graphics/ multimedia files (Maher & Simoff, 1998). Both technical and managerial approaches have been investigated for the purpose of improving information integration (Fisher & Kunz, 1995). These approaches involved the use of a centralized project model that adopts data standards ranging from the previous ISO-STEPS to the recent IFC, in which structured data integration was the primary concern. Apart from that, some recent researches started to take unstructured data integration into consideration. Amongst these efforts were design tool that could capture, share and reuse project information (Fruchter, 2002), approach that could extract concepts from textual design documentation, the use of arbitrarily metadata that could markup documentation (Briiggemann et al., 2000), as well as the use of controlled vocabularies that could integrate heterogeneous data representations (Kosovac et al., 2000). Apparently, metadata has been one of the approaches under investigation by the A/E/C professionals which tended to improve data integration. 3.4 The current practice The use of project web by the A/E/C professionals becomes more and more widespread. However, the conscious use of metadata in the construction industry is seldom. The use is often limited to unconscious use of more or less occasional metadata elements in desultory situations. Therefore the potential benefits of using metadata have decreased.

An ontology-driven approach for monitoring collaborative

531

3.5 Case studies Several semi-structured interviews were conducted by the author of this paper to investigate project webs operated for the building industry. During the interviews, limitations of project webs with respect to their respective efficiencies in information dissemination were delineated by the interviewees, and were described hereafter. Information was first categorized based on some sort of relations, and was then archived under different electronic file folders corresponding to the information categories. Semiand unstructured information such as briefing notes, design rationale, and e-mail messages, was usually not stored in the project web. In general, e-mail messages were collected in another project-level digital information source while the paper-based information was kept in company-level paper-based archives such as filing cabinets. Drawings were generated at every stage with respect to the change of design, but only the final version was uploaded to the project web. In brief, such descriptions reflected the implication of fragmentary communication and information flow in project web. As a consequence, project web turned out to be highly dependent on inefficient human efforts in processing such as searching, browsing and extracting the stored information. Comments about the contribution of project web in the regular basis design progress meeting were also given by interviewees. It was commented that, meeting participants (i.e. project team actors) required spending rather long time to read a specific piece of information in order to comprehend its context during the discussion in the meeting. It was also observed that meeting participants faced the difficulty of finding a specific piece of document during the meeting, particularly when the need of the specific document arose at random. On the other hand, the person who was responsible for making meeting minutes tempted to capture the discussion content on papers. The captured information would then be transformed to digital format with word processor tool after the completion of the meeting before it could be uploaded to project web, which resulted in repetition of workload. The conventional notes-taking approach also structured the meeting summaries in tree-structure format with design rationales and decision intent implicitly contained in written plain text. The implicit design rationales and decision intents could only be interpreted rapidly by those who attended the meeting and actively joined the discussion. For those who did not participate the meeting but were interested in following the design progress, extra time needed to be spent to collate and review the series of meeting minutes that were stitched with time element. The conventional meeting minutes were also incapable of integrating pieces of design information that had been produced throughout the early design process. This increased the time needed to review the stitches of meeting minutes in particular when the necessity to gather the relevant but scattered design information arose. 3.6 The analysis of questionnaire survey The Danish National Agency for Enterprise and Housing conducted a series of questionnaire surveys to study a blend of eight Danish and international project webs to what extent metadata was applied in their respective systems (NAEH, 2004a). The purpose of the study was to understand the current situation of metadata implemented in order to look into potential improvements when necessary. The analysis with respect to the result of the survey study indicated that there was between the systems a big diversity

eWork and eBusisness in architecture, engineering and construction

532

if users were obliged to use metadata to connect to files. Only in half of the systems a search on metadata could be done otherwise they were just indicated when the user browsed the files. In fact, it was only possible to make a direct search on metadata in very few systems. User reactions therefore claimed that the retrieval of documents often took place in a list named e.g. ‘New Documents’ or ‘Since last Time’. This list was sorted by date and contained therefore documents concerning quite different subjects. The list was emptied after each visit and the documents were automatically stored in folders that corresponded to categories of the different subjects. This user pattern illustrated the unawareness of users with respect to the functionalities of the system or more likely that document retrieval functioning on metadata was poorly developed. The connection of metadata to files was either done automatically by the system or manually by the user. The automatically connected elements were often of the type as Date, User ID and File Name (NAEH, 2004b). Only a few elements such as Document Number and Revision were mandatory while the rest were optional. The optional elements were sometimes used with different approaches or just ignored by the system user. In most cases, the metadata elements did not follow a common standard. The elements were defined on the basis of the provider’s preferences indifferent of actual user needs or patterns. The standards that were used to define the metadata elements were either out of date or uncommonly used and therefore useless (NAEH, 2004b). For the further work with metadata in project webs systems with respect to these shortcomings, it would be naturally to follow a standard. ISO/IEC 82045–5 ‘Document management—Part 5: Application of metadata for the construction and facility management sector’ which is a standard for the utilization of metadata in the construction industry providing four metadata sets each of which directed to specific phases of the construction process (ISO/IEC CD 82045–5). The standard is under development. For some project team actors such a standard would make some limitations to their work procedure and require modifications, but in accordance with common understanding ‘a poor standard is better than no standard’. With the standard proposed by ISO/IEC 82045–5, it would be possible to raise the use of project web systems from merely document containers to more intelligent document management systems. By following a standard the users would be presented with the same user interface independent of which project web system the actual construction project is using. The transfer of data from one system to another would become less problematic. 4 THE HYPOTHETICAL SYSTEM 4.1 The concept With reference to the comments given by interviewees and the analyses of questionnaires survey, a semantic web based knowledge management system is developed to improve the management of project information which is a crucial means to enhance collaboration amongst project actors (Lai et al., 2002; Lai et al., 2003). The system is primarily devised to integrate pieces of information generated at the iterative early design stage in order to provide decision making support in a multi-actors environment where information is

An ontology-driven approach for monitoring collaborative

533

archived in heterogeneous sources. Pieces of information in this case are hypothesized as information chunks which respectively represent different discussion issues in a meeting. Each of these issues can be represented as an object while document is represented as the container for the information objects (Fig. 1). Annotate information chuck with metadata is a method to integrate information in a way to make the relationships between the different pieces of information explicit. Progress meetings are one of the important collaboration activities since the project outset. Notes-taking has been a common practice to record discussion content of a meeting. This prototype system is thus

Figure 1. Representations of information and document. developed to support progress meeting, and meeting minutes is chosen as the medium for integrating information. The prototype may be an alternative method of capturing discussion content of design progress meetings rather than the conventional notes-taking

eWork and eBusisness in architecture, engineering and construction

534

approach. In light of the limited use of conventional meeting minutes, the prototype system is also devised to provide fast and precise semantic search, and to capture the intent and rationale behind decisions made during the early design process. The prototype system is envisioned to fulfil the following tasks: – To integrate information that is distributed in heterogeneous sources without using one central repository to reduce repetition of workload. – To capture and store discussion content wherein design rationale and decision intent are intrinsically encompassed. – To organise the captured information in a way that is both human and machine readable. – To contextualise the captured information in representation that may improve the human’s efficiency to interpret its implicit meaning. 4.2 The tools used The semantic web (Bernes-Lee, 2001) technologies were chosen as the core of the prototype system. In order to fulfil its tasks, the prototype system was built based on an underlying ontology model so that the discussion content is organized in a semanticbased network. Resource Description Framework and its Schema (RDF(S)), the de facto standards proposed by the industry group W3C (W3C, 2002) are adopted to develop the ontology model of the prototype system mainly due to the availability of several open source RDF(S) tools. Protege 2.01, an open source ontology editor is used to develop the form-based user interface of the prototype system. This user interface is to facilitate the system user establishing RDF data file based on the lightweight ontology model, which is written in RDFS. Sesame 1.0 (detail see http://sesame.aidministration.nl/), an open source RDF(S) based repository and querying facility is used as the development base of the prototype system. RQL, query language used in Sesame, is also implemented in this prototype system as the means of accessing information in RDF(S) (detail see Broekstra & Kampman, 2001). 4.3 The implementation The underlying ontology model of the prototype system consists of a few modular components, which respectively is ontology, as illustrated in Figure 2. Each of these ontologies describes another aspect of interest, for instance the ‘team-profile ontology’ describing the profile of the design team. The modular characteristic with respect to the ontologies network streamlines the prototype’s flexibility for future expansion. Each modular component within the ontologies network is accessible through uniquely specified URI (Uniform Resource Identifier). This modular characteristic permits the scattered information including the existent data and the respective ontologies not to be collected under one central repository.

An ontology-driven approach for monitoring collaborative

535

Figure 2. The modular characteristic of ontology network implemented in the prototype. Form-based user interface is chosen as the mechanism to annotate the content of the meeting minutes with a set of metadata that is pre-defined in the ontology model, including Infoblock Author (denotes the person who raised the discussion issue), Discussion Date, Text (denotes the discussion content), Title (denotes the title of the discussion issue) and so forth. With this set of metadata, the content of the meeting minutes could be semantically structured, and become readable to the machine and easily interpretable to the human. As shown in Figure 3, for instance: Joe Young illustrates that “Joe Young would take the action” on “something” that was discussed in the meeting. The form filling user interface is chosen because form-filling has been a familiar activity for most computer users. The filled-up form represents a dynamic meeting minute with all of the annotated information populates in the RDF(S) based repository. The annotated information can be stored separately from its corresponding ontology. Queries can be established by system user to initiate semantic search (for details please see Lai et al., 2003). The searched result, which is a list of URIs, is accessible to the system user provided that all of the relevant repositories are connected to the Internet.

eWork and eBusisness in architecture, engineering and construction

Figure 3. The form filling user interface supported by the prototype to generate dynamic and semantic structured meeting minutes.

Figure 4. The contextual map feature supported by the prototype as a means to make the relations between issues explicit based on reasoning derived from the ontologies network.

536

An ontology-driven approach for monitoring collaborative

537

5 DISCUSSION The prototype is to test if ontology-driven approach is contributable to collaborative design knowledge management. At this stage, the reasoning structure of the prototype system is evaluated by populating instances to the underlying ontology model via the form-filling user interface. The interim findings have identified that the current metadata initiatives are insufficient for the prototype to fulfil all of its tasks. These initiatives focus on the encoding of primary content attributes of resources (e.g. documents, datasets, etc), such as author, date, location ID, and so forth, with the purpose merely to improve information retrieval and interoperability. In order to fulfil all of its tasks, the prototype system is devised one step forward to take the challenge claimed by Goel (Goel, 1995), which is to provide possible means for analyzing the contents from group discussions so that the idea flow can be traced. Ideas with respect to various issues were generated, shared, and discussed during the design progress meetings. These ideas comprise newly defined or existing design problems, propositions to solutions, as well as the solutions themselves. The relationship between these ideas was implicitly written as plain-text messages in the conventional meeting minutes. The implicit relationship between these ideas can be made explicit by contextualizing them with reference to the propositions given by Shum et al. (2002) so that the flow of ideas can be traced, i.e. 1. The intellectual lineage of ideas, for instance, where has this idea come from, is this idea a problem or proposition, has this problem been solved, are there any precedent cases? 2. The impact of ideas, for instance, what was the impact of this proposition to its problem and to other proposition? 3. Inconsistencies, for instance, did the solution gain unanimous agreement from the project team, what was the reason given as opposition? Contextualizing information in such a way is similar to overlaying interpretation of contents explicitly based on the semantic network derived from the underlying ontology model. As shown in Figure 4, the contextual map, which is part of the prototype system devised for this purpose, allows system users to model the semantic relationships between information graphically by binding the different sets of annotated ideas with context dependent relations (or properties as defined in RDF(S)). Please see Lai (2004) for the detailed explanation with respect to this knowledge authoring approach. With reference to Figure 4, and were two of the examples of metadata used in the prototype system to annotate the information content, and solved_by was the example of relations used to disclose the semantic relationships between information. Briefly, disclosing the semantic relationships between information graphically as illustrated in Figure 4 may reduce the time users will spend to digest the non-relevant information and therefore enable the users to manage information of interest more efficiently. At this stage, metadata used in the prototype was arbitrarily defined based on its meaning in natural language. Vocabularies were chosen on the basis of their expressive semantic in describing collaborative design process. Use of arbitrary metadata is a pitfall

eWork and eBusisness in architecture, engineering and construction

538

that may hinder effective information interoperability as already identified in the project web system in Section 3.6. 6 CONCLUSION & FUTURE WORK Design rationale and decision intent are intrinsically contained in the discussion content of the design progress meeting. Discussion content has been conventionally captured in meeting minutes simply as a piece of plain-text document written in natural language. This piece of document is circulated amongst the project team actors. Sources of design information that is referred to during discussion are usually specified in this plain-text record. By making use of the technologies of Semantic Web and ontologies, the conventional meeting minutes is envisioned upgradeable to a dynamic and semantically structured medium. The implication is that this medium may handle the mass quantity of design information effectively by eliminating repetition of workload. The dynamic meeting minutes may also allow the design intents be explicitly presented instead of implicitly described in plain-text records. This envisioned system will be a medium for project team actors to manipulate (store, index, search and retrieve) knowledge as well as the corresponding meta knowledge effectively The proposition of further research is to examine the possibility of incorporating the standards for metadata as proposed by the ISO/IEC 82045–5 in the ontology modeling process. This consideration may avoid repeating the same imperfection of project web while offering a coordinated strategy for better mapping of metadata between different knowledge management systems. A promising standard may adapt the prototype knowledge management system not only sufficient to serve the early design stage but also to serve the whole building life cycle. REFERENCES Archer, G.O., Futcher, K., McMahon, M.A. 1997. IT support for construction re-engineering. Robin Drogemuller (ed). CIB Proceedings. Publication 208. JamesCook University of North Queensland. Bernes-Lee, T., Handler, J., Lassila, O. 2001. The Semantic Web A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities. Scientific American. 284(5):34–43. Broekstra, J,. Kampman, A. 2001. Query Language Definition, On-To-Knowledge Project Deliverable 9. Project EU-IST On-To-Knowledge IST-1999–101. Brüggemann, B.M., Holz, K.-P., Molkenthin, F. 2000. Semantic documentation in engineering. Proc of the ICCCBE-VIII, Palo Alto, CA: 828–835. Davis, J., Fensel, D., Van Harmelen, F. (eds). 2003, Towards the semantic web: ontology-driven knowledge management, John Wiley & Son Ltd. Fischer, M., Kunz, J. 1995. The circle: architecture for integrating software. Journal of Computing in Civil Engineering, 9(2):122–133. Fruchter, R. 2002. Metaphors for knowledge capture, sharing and reuse. in Turk & Scherer (eds.). Proc of eWork and eBusiness in Architecture, Engineering and Construction, ECPPM Conference 2002:17–26. Goel, V., 1995. Sketches of Thought, Cambridge, MA: MIT Press.

An ontology-driven approach for monitoring collaborative

539

Kosovac, B., Froese, T., Vanier, D. 2000. Integrating heterogeneous data representations in modelbased AEC/FM systems. Proc of CIT 2000. Reykjavik. Iceland. 1:556–566. Lai, Y-C. 2004. Contribution of semantic web to collaborative design. In Proc of the 9th CAADRIA2004 Conference. Seoul: 28–30 April, 91–106. Lai, Y-C., Carlsen, M., Christiansson, P., Svidt, K. 2003. Semantic-web supported knowledge management system: An approach to enhance collaborative building design. in Proc of ASCE Nashville 4th Joint Symposium on IT in Civil Engineering, Nashville: 15–16 November. Lai, Y-C., Christiansson, P., Svidt, K. 2002. IT in Collaborative Building Design (IT-CODE), in Y.Rezgui, B.Ingirige & G.Aouad (eds.), Proc of the European Conference on Information and Communication Technology Advances and Innovation in the Knowledge Society, eSM@RT 2002 in collaboration with CISEMIC 2002, University of Salford, UK: November 2002, 323–33 l(PartA). Maher, M.L., Simoff, S.J. 1998. Ontology-based multimedia data mining for design information retrieval. in Proc. of Computing in Civil Engineering, ASCE: 212–223. Mesquita, M.J.M., Fabricio, M.M., Melhado, S.B. 2002. E Concurrent engineering in construction: studies of briefdesign integration. Proc IGLC-10. Gramado Brazil. NAEH (The Danish National Agency for Enterprise and Housing). 2004a. Analysis B. Projektwebkonsortiet: Bygherrekrav-projektweb Delrapport B-Analyse af Projektweb. Project Web Konsortium. Copenhagen. NAEH (The Danish National Agency for Enterprise and Housing). 2004b. Analysis C. Projektwebkonsortiet: Bygherrekrav-projektweb Delrapport C-Datanalysen. Project Web Konsortium. Copenhagen. Nonaka, I., Takeuchi, H. 1995. The knowledge creating company, Oxford University Press. Oxford. Shum, S.J.B., Uren, V., Li, G.M., Domingue, J., Motta, E. 2002. Visualising Internetworked Argumentation. in P.A.Kirschner, S.J.B.Shum and C.S.Carr (eds.). Visualising Argumentation: Software Tools for Collaborative and Educational Sense-Making. Press. Springer-Verlag. London: 185–204. W3C. 2002. RDF Vocabulary Description Language 1.0: RDF Schema. W3C Working Draft 30 April 2002. http://www.w3.org/1999/02/22-rdf-syntax-ns#

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Setting up the open semantic infrastructure for the construction sector in Europe—the FUNSIEC project C.Lima, B.Fiès & C.Ferreira da Silva Centre Scientiflque et Technique du Bâtiment, Route des Lucioles, Sophia Antipolis, France S.Barresi Information Systems Institute, University of Salford, UK ABSTRACT: This paper describes the work to be done by the FUNSIEC project, which aims to evaluate the feasibility of building an Open Semantic Infrastructure for the European Construction Sector (OSIECS). Such an infrastructure is to be built by selecting semantic resources devoted to construction in different languages, exploiting some public results produced by international initiatives (e.g. IFC) and European funded projects. OSIECS will be open to any linguistic resources; in particular those developed for less widely spoken languages and those of the Candidates countries. The innovation in OSIECS is to be on the semantic mappings to be established among the existing semantic resources. The assessment of the results produced by FUNSIEC is centred on the main subjects: its business plan and the education (in the large sense) of the practitioners from Construction regarding the use of semantic resources.

1 INTRODUCTION Historically, construction projects have been organised on a local or national basis. Construction, over the last decades, has become a global industry, with a variety of activities, carried out on an international scale. For instance, the process of design has followed international practice of creating a supply chain of independent companies, each adding value in a particular area. The result has been a large number of SMEs representing architectural practices, and firms of structural and building services engineers. This situation results in a very highly fragmented, heterogeneous, chain of information (complying with diverse official and de facto standards) in the building process. One of the major consequences in this scenario is the difficulty to communicate effectively and efficiently among partners during a building project or between clients and suppliers of construction products. This is a well-known problem, and several European and international initiatives have tried to overcome this problem by producing dictionaries, thesauri, and several semantic resources (e.g. BS6100 glossary, the e-

Setting up the open semantic

541

Cognos ontology, the LexiCon, bcXML Meta-schema/Language) focused on Building and Construction terms to facilitate communication and improve understanding among the various stakeholders operating on a construction project. However, even considering the convergent efforts found in some initiatives (e.g. the eCOGNOS ontology uses IFC concepts and is bcXML-compliant), most of these semantic sources are non-interoperable and cannot be easily used by either service providers or users in general. There is a need to gather and characterise all these resources, establish semantic links among them and make them available through a single access point. Moreover, this structured pool of resources should be open to new resources in order to extend its scope by taking into account new sub-domains or new languages. The feasibility study to be carried out by the FUNSIEC intends to provide an answer to this need. This paper is structured as follows. Section 2 describes the context of work in which FUNSIEC is developed. Section 3 discusses the FUNSIEC approach. Section 4 presents the inputs used in FUNSIEC. Section 5 reports the current status of the project and the problems envisaged. Finally, Section 6 concludes the paper including the work to be done. 2 CONTEXT OF THE WORK The general aim of the FUNSIEC project is to study the feasibility of building and maintaining an Open Semantic Infrastructure for the European Construction Sector (OSIECS) at a technical, organisational and business level. Such an infrastructure is to be built by gathering semantic resources devoted to the construction sector in different languages, including public results produced by international initiatives and EC-funded projects. OSIECS will be made available to content and service providers, as well as to other actors in the construction area, to help them exploit fully the advantages of Construction-oriented semantic-based e-resources. FUNSIEC is also committed to evaluate the best alternatives to set up and maintain semantic mappings amongst the available (semantic) resources, in order to foster the complementarities among these diverse resources and favour the emergence of new services, especially those supporting multiple languages. These mappings are to be supported by a neutral language-independent representation of construction concepts, where the promising candidate is the recommendation from the Semantic Web group, the OWL language. In order to develop OSIECS, the work to be carried out in FUNSIEC follows major trends and strategies currently in place in Europe on one hand and, on the other hand, it can (likely) be a good mechanism to provide answers to the business needs related to the use of what is named Semantic Resource (SR) in FUNSIEC. A Semantic Resource is a generic term used to refer dictionaries, taxonomies, ontologies, and other similar types of resources where semantics play a crucial role. A good reference taken by FUNSIEC is the eConstruction Workshop, which was performed under the umbrella of the European Committee for Standardization (CEN). This workshop, which was actually a series of workshops helped by the SPICE project1, produced a number of CEN Workshop Agreements (CWAs) on ICT-related matters

eWork and eBusisness in architecture, engineering and construction

542

covering an architecture identifying an infrastructure and some of its actual key components (meta-schema, SRs and supporting software tools), all relevant in the context of Construction Processes. All in all, FUNSIEC’s work considers four major points, namely: (i) the state of the art in relation to the development and use of construction-oriented semantic-based eresources; (ii) the identification of appropriate e-services (supported by existing or to be developed tools) that could exploit OSIECS; (iii) the definition of relevant and pragmatic partnerships (including content and service providers) likely to sustain the development and ensure the business viability of OSIECS; and finally (iv) an implementation plan recommending the future actions to be performed in order to maintain and enrich OSIECS. 2.1 The FUNSIEC vision The FUNSIEC project is not a classical RTD project. Rather, the “feasibility” parameter drives the work toward a pragmatic analysis of the potential business-oriented benefits that can be achieved by the construction sector in general and by the content/service providers in a more specific way. It is true that there is a gap between the results delivered by researchers and their adoption by the industry. This is the way of foreseeing the future of the business. However, sometimes the language and the mechanisms used to promote the research results are not elaborated from the viewpoint of the final users. FUNSIEC is committed to help “educating” the construction sector over the theme “semantic resources” considering that semantics/meaning can be used to raise the gains of the sector. 2.2 Rationale and motivations FUNSIEC work is committed to help finding answers to the requirements identified by the CEN/ISSS roadmap that have to be fulfilled in order to put in place the eEurope 2005 goal: interoperable systems, common resources of open and accessible content, and guidance through examples, awareness and training. One fundamental element in the standardisation domain is the collaborative work required to keep up and maintain the promotion of the standards. The alliance of key players from the domain is vital in this process. FUNSIEC targets this matter by promoting the partnership of European (and not only) organisations that can contribute to produce better results as well as to disseminate them. Equally relevant in FUNSIEC work is the (e)business side of the story. FUNSIEC intends to be an instrument to help promoting e-business practices into the construction community. The goal is to become the landing place for the sector where people can get “educated” by knowing the SRs currently available and potentially usable by construction in Europe, by seeing usage scenarios for these SRs, and by having access to on-line tutorials and demonstrations of the software tools (films or simple mock-ups) handling the SRs. The success of FUNSIEC is to be assessed by three main results: the quality business plan, the establishment of the so-named “FUNSIEC Semantic Experience Centre”, and the OSIECS infrastructure. The first is to be used as an instrument to support the

Setting up the open semantic

543

development of new businesses exploiting the available semantic resources for the construction sector. The second, a very ambitious one, is to be used as the main “instrument” in the FUNSIEC quest towards the education of the construction sector over semantic-related matters. Finally, the third one will rely on the 1

SPICE project is an European initiative that was over May 2004. Its main goal was to produce a set of CEN Workshop Agreements (CWA) in order to support the establishment of the eConstruction (e-world for Construction) in Europe.

technical quality of OSIECS, especially considering its openness, simplicity, and usability. 3 THE FUNSIEC APPROACH (CS) 3.1 General overview FUNSIEC targets the current situation where there are standards (both official and de facto), classification systems, taxonomies, ontologies, and related technologies and tools that are used either in a complementary or in a completely isolated way, in order to produce the framework—OSIECS in Figure 1—where the above mentioned elements can be combined in a inter-related and holistic fashion. The OSIECS Kernel represents the holistic inter-link connecting a plethora of different existing semantic e-resources targeting the BC sector. Additionally, this kernel is to provide an “open door” through which new e-resources can become integral part of OSIECS in the future. FUNSIEC intends to carry out feasibility study targeting four major points, namely: – The state ofthe art analysis: analysis and evaluation of the current situation in Europe regarding standards (official/de facto), classification systems, taxonomies, ontologies and the related technologies and tools currently available. – Services characterisation: description of the electronic services that could represent a benefit for the building actors. Some examples of such services are the following: publication and management of electronic catalogues of products, standard-based search of construction products across multiple catalogues (one single query, several searches through multiple catalogues), and ontology-based search of knowledge; – Partnerships: on one hand, this is related to the identification of the more representative organisations in Europe that must work together in order to produce OSIECS. On the other hand, this includes the setting-up of a set of procedures (likely supported by rules of cooperation, formal organisational models and tools) aiming at enabling small (but not less important) organisations and their respective resources/initiatives (e.g. regional dictionaries) to be incorporated as part of the FUNSIEC framework. – Implementation plan: this is the definition of the various actions required to foment the cooperation among the institutions identified for the partnership, taking as input the analysis of the state of the art and the added-value services to be built upon OSIECS.

eWork and eBusisness in architecture, engineering and construction

544

Beyond the “simple” pooling of linguistic resources, the project aims at creating a harmonised environment where each resource is clearly characterised

Figure 1. The FUNSIEC framework.

Figure 2. Three layers in the FUNSIEC framework. (content, scope, usage…) and situated in the overall map of resources, and where semantic links are created among these resources. The lack of “educated users” is one of the main factors explaining why the existing SRs have not been used more intensively. Moreover, the creation of consistent linguistic resources is most often a tedious task for content providers with no warranty on the real profitability of the effort. This is certainly a major challenge of FUNSIEC to force these bottlenecks and create the interest and confidence needed for both content and service providers. This aspect is a potential risk of failure that has to be carefully evaluated during the project.

Setting up the open semantic

545

3.2 Three-layers based modelling All semantic resources follow some underlying meta-model and model, even if some times they are not explicitly stated. In order to enable interoperability between different Semantic Resources it is unavoidable to state and understand what meta-models they follow, beforehand. Modeling at three levels of abstraction is explained in this section. The CEN/ISSS eConstruction Workshop recommends the use of frameworks structured in two levels, namely meta-schema and schema. FUNSIEC considers a third level in this framework, the instances (Fig. 2). At the highest level, there are metaschemas that describe very general and abstract concepts that are

Figure 3. Fundamental concepts around Semantic Resources. necessary in the structuring of an information model and those that describe broadly sharable ideas usually being specific to building construction. A metaschema can therefore be seen as a schema on a high level of abstraction. In the second level, the schema represents an agreed structure expressed in some suitable and mostly formal language for describing the things on the different “description levels” (e.g. a taxonomy or an ontology). It should be able to handle both definitions and specifications (types and occurrences) of construction-related products and services. Finally, in the bottom level, instances are very specific representations of a schema, for instance a catalogue of products where all the properties that define a given product has the right values defined (e.g. catalogues of products). From a top-down perspective, specialisation is the axis transforming a meta-schema into instances and generalisation supports the other way round. In other words, the lower levels represent more detailed and concrete information whilst higher levels mean more abstract things. The lowest levels are more tangible and more clearly understood by the ordinary users. At the different levels, the FUNSIEC framework is to be designed taking into account the following references, namely: the IFC model, The R&D projects eConstruct and eCognos, the CEN/ISSS eConstruction Workshop Agreements, the ISO DIS12006–32, and the recommendations from the Semantic Web group.

eWork and eBusisness in architecture, engineering and construction

546

3.3 Three-layers based modelling The fundamental definitions around the term “Semantic Resources” considered in FUNSIEC are the following (Fig. 3): – Classification system/Thesaurus: a classification system is a dictionary where the terms are related via some human-made, human-friendly ordering relations. A classification not involving specialisation but more general broader/narrower relationships is often referred to as a Thesaurus. These “weaker” relations typically stand for some abstraction of specialisation and/or decomposition; – Dictionary: a reference list of technical terms (words) with their definitions. The simplest dictionary, a defining dictionary, provides a core glossary of the simplest meanings of the simplest concepts; – Ontology: denotes a (typically shared) understanding of a particular domain in terms of concepts (abstract ideas having some semantic value) which are inter-connected through a set of relevant relations. An ontology can be seen as a hierarchy of concepts that becomes complete with a taxonomy of relations that is applied to it. – Taxonomy: is the “backbone” or “skeleton” part of an Ontology. A taxonomy is a hierarchical specialisation tree/network structure of Concepts (i.e specialisation/generalisation is one of the standard Relations); – Vocabulary: is an (alphabetical) list of technical terms (words) in a given language. Usually, in a specialised field of knowledge such as in Building and Construction domain, those terms, or couple of terms, intend to represent concepts.

4 THE REFERENCES USED IN FUNSIEC The most relevant projects, initiatives and semantic resources currently available for the construction sector in Europe are shortly described in this section. 4.1 Results produced by the European RTD projects 4.1.1 The bcBuildingDefinitions taxonomy The eConstruct project developed a communication technology called Building and Construction eXtensible mark-up Language (bcXML). It provides the European Building and Construction industry with a powerful but low cost XML-based language that primarily supports the e-business communication needed between clients, architects, engineers, suppliers, and contractors for the procurement of products, components, and services (Tolman et al. 2001). In order to enable the bcXML communication lan guage to be demonstrated and tested, the bcXML Reference Architecture was designed and a prototype demonstrator was implemented. A number of client applications have also been implemented within the prototype and demonstrated the proof of concept for bcXML. The bcBuildingDefinitions is the taxonomy developed by the eConstruct project in order to demonstrate the power of bcXML. It supports the “Objects

Setting up the open semantic

547

2

The ISO standard proposes a model to guide the development of taxonomies for Construction. It is used by some SRs currently available in Europe, namely the LexiCon (the Netherlands), Barbi (Norway), and Edibatec (France).

of interest” that were used in the eConstruct end-user demonstration scenarios and concentrates on the context of Buildings, especially Doors. It contains nearly 3000 terms specifically related to doors and expressed in the following languages: English, French, Dutch, German, Norwegian, and Greeklish3. The bcBuildingDefinitions can be instantiated to create catalogue contents or the actual requirements and solutions messages. For example consider that a user wants to get quotations from a number of door suppliers that meet the following specification: “5 no. I hour fire resistant, internal solid core doors, Ash veneered and lippings on both faces, door leaf height 2040mm and width 826mm”. The bcXML is primary capable of supporting simple eCommerce communication of products (materials, components, equipment, documents) and services inside or over the national borders. Users can specify the content of their messages (both supply and demand) in terms used in the building and construction industry. Simple, small and clear XML code is generated. Both B2C/C2B and B2B communication are provided. The bcXML is also able to communicate with external taxonomies that add more complex structuring mechanisms like specialisation, decomposition, or views. The demonstration scenarios used in eConstruct show the use of bcBuildingDefinitions. A given company is searching for a specific timber flush door. Using their software tool or via the eConstruct Browser, they query the taxonomy server in order to get the product they are looking for. They have access to the structure of the door, they fill in the properties they are interested in and search in their native language (assuming English) through French and German catalogues. If the product is found, the company receives a list of the products currently available. The bcBuildingDefinitions is used to provide the structure of timber flush door and to help the translation of the query in different languages, since each element/concept in the taxonomy is represented in several languages. 4.1.2 The e-COGNOS ontology The e-COGNOS IST project developed the e-COGNOS Knowledge Management Infrastructure (e-CKMI), a Web-based KM solution targeting the needs of the Construction industry. Two concepts are fundamental in the e-CKMI: Knowledge Items (KI) and Knowledge Representations (KR). The former are the real pieces of knowledge (documents, experts, projects, organisations, etc.) and the latter are the respective representation of KIs within e-CKML In other words, each KI is represented by a KR within e-CKMI (Lima et al. 2003).

eWork and eBusisness in architecture, engineering and construction

548

Figure 4. The e-COGNOS conceptual architecture The e-CKMI has been developed as a middleware solution offering web services to support KM needs in construction companies (Fig.4). Essentially, it is composed of a set of KM Core Services representing the vital functionalities within the system. These services have been structured into the seven categories of knowledge-related functionalities identified in a classical KM life cycle: acquisition, cleansing/ transformation, indexing, updating, refreshing, searching/discovering, and sharing/dissemination. The KM services are supported by e-COSer, the “ontological pillar” that helps these services perform their tasks in a semantically richer way Fundamentally, the e-COSer is called to help prepare the best ontology-based indexes to index and find KRs. In order do that, e-COSer uses the e-COGNOS ontology, a semantic resource domain-specific created to support the construction needs in the context of the development of construction projects. The e-COGNOS ontology focuses on construction concepts as they relate to eCOGNOS main objective: consistent knowledge representation of construction knowledge items. Such an ontology was developed taking into account relevant sources of inspiration, namely the IFC model, the bcXML MetaSchema, the BS6100 Classification, and the DAML+OIL language, as shown in the table below. The conceptual model of the e-COGNOS ontology is based on the bcXML metaschema. In the development of the e-COGNOS ontology, a taxonomy is considered as the cornerstone upon which all the subsequent developments are based. The e-COGNOS ontology is essentially composed of two taxonomies, namely a taxonomy of concepts and a taxonomy of relations. The taxonomy of concepts is grounded on the IFC concepts, which are used to form its highest levels. Essentially, the e-COGNOS ontology is used to support KM practices, such as knowledge acquisition, indexation, search, etc.. The e-COGNOS Infrastructure (e-CKMI) acquires “Knowledge Items”—KI (e.g. documents, experts, organisations, projects, etc.) and

Setting up the open semantic

3

549

Greek language written with Latin characters.

creates the respective “knowledge representation” (KR). This KR is then indexed through keywords and ontological concepts. In the search process, the ontology is used to support an so-named “advanced process” where the user can browse the ontology in order to prepare his/her query in a more precise way. A group of four end users assessed the e-COGNOS ontology as part of the e-CKMI tool as well as in an isolated way. In the first case, the ontology was used to provide “ontological references” to index their KIs. As expected, the results reported showed that better answers were obtained when using ontological indexes. In the second case, the users were invited to play the role of administrator of the ontology. Positive results and precise criticisms were acquired, showing that ontologies (or semantic resources in general) are not so well understood by ordinary users. This conclusion provides precious insights regarding future works on this area. The e-COGNOS vision over the development of a big ontology was confronted with an unexpected reality. The users actually showed their preferences to use their very specific, concise and precise taxonomies. They do not want to handle big ontologies; rather they are perfectly happy if their small resources are in place providing the results they are expecting. This fact has changed the concept of the e-COGNOS ontology: the big ontology is available but it is totally customisable in the sense that a small taxonomy with 100 concepts can replace it. 4.2 The IFC model The primary target of the IFC model is the interoperability among software applications within the building and construction market sector. IFC classes are therefore defined according to the scope and the abstraction level of software systems dealing with building and construction specific content. Thus, the IFC model has not been developed as an ontology per se, however its object model is structured according to principles that are common with other semantic resources (CWA3 2004). These concepts (or “terms”) are defined as follows: – As predefined concepts (of IFC classes and relations), if such concepts are commonly used across many general and construction domain specific software products. These “statically” defined concepts allow to speed-up the exchange and sharing of information and reduce the risk of ambiguous interpretation; – As open concepts (of IFC proxies for classes, or IFC property sets for attributes), if such concepts are subjected to deep domain knowledge or are specific to certain localities. These “dynamically” defined concepts allow to enhance the scope of terms used within IFC by enabling the IFC model to be extended by the use of an external classification or taxonomy concept. The predefined concepts form a well defined hierarchy of terms in the sense of a taxonomical hierarchy. At the leaf nodes of that hierarchy more dynamic means to extend the definitions (like enumeration for special occurrence types or type objects for common types) towards more granularities.

eWork and eBusisness in architecture, engineering and construction

550

The IFC model comprises several schemas that are organised according to the layer they belong to. The schema IfcKernel defines the most abstract part within the IFC architecture which contains the most abstract IFC entity—the IfcRoot. Each entity defined in the core, interoperability or domain layer of the IFC model inherits (over some intermediate steps) from the IfcRoot entity. It provides for the fundamental properties of identification, ownership and change information, and optional label attribution. There are three fundamental entity types in the IFC model derived from the IfcRoot, that form the first level of specialization within the IFC class hierarchy, namely: – Objects are the generalisation of any semantically treated item within the IFC model. An object can be: the abstract supertype, all physically tangible items physically existing items or conceptual items, processes, controls, resources or actors. An object gets its context information from the relationships it is involved in. – Relations are the generalisation of all relationships among items that are treaded as objectified relationships in the IFC model. A concept of relationships is the objectified relationship—IfcRelationship—which is the preferred way to handle relationships among objects. This allows to keep the relationship specific properties directly in the relationship object and to uncouple the relationship semantics from the object attributes. The introduction of the objectified relationships also allows the development of a separate subtype tree for the relationship semantics. – Properties are the generalisation of all characteristics (either types or partial type, i.e., property sets) that may be assigned to objects. The property definition— IfcPropertyDefinition—is the generalisation of all characteristics of objects. It reflects the specific information of an object type, versus the occurrence information of the actual object in the project context. The property definition gets applied to the objects using the concept of relationships. The entities of the IfcKernel schemata are organised in a taxonomy, which is not the case for the entities belonging to other schemas. This is a consequence of the object oriented approach of the IFC model. In that case, there is no real need for an explicit organisation of the concepts; rather the IfcEntities are related among themselves through explicitly defined relations. 4.3 The ISO 12006–3 family ISO 12006–3 is a Construction specific standard that defines a schema for a taxonomy model, which provides the ability to define concepts by means of properties, to group concepts, and to define relationships between concepts (Fig. 5). Objects, collections and relationships are the basic entities of the model. The set of properties associated with an object provide the formal definition of the object as well as its typical behaviour. Properties have values, optionally expressed in units (CWA3 2004). The role that an object is intended to play can be designated through the model and this provides the capability to define the context within which the object is used. Each object may have multiple names and this allows for its expression in terms of synonyms or in multiple languages. The language name of each object must always be given in English (the default language). An object may also be named in terms of the language of

Setting up the open semantic

551

the location in which it is determined or used. Objects may be related to formal classification systems through the provision of references. Two applications of this standard are evaluated by FUNSIEC here, namely the LexiCon (Netherlands) and BARBi (Norway). 4.3.1 The LexiCon (Netherlands) The LexiCon is a vocabulary of terms of interest for the construction industry and as such an implementation of ISO DIS 12006–3. The LexicOn is a structure for the storage of data in such a way that—within a certain context—the meaning of these data is assured. The LexiCon therefore can be regarded as a semantic system, defining the context for data explicitly and defining contexts within broader contexts (Wostneck 2003). The context of the LexiCon is specific to the construction sector. In the LexiCon, all the construction objects of interest (including materials and products) are grouped under the heading Subject, everything dealing with the production process (maintenance, demolishment and use) is grouped under the heading

Figure 5. Top level structure of ISO 12006–3. Activity. The LexiCon only contains generalizations of Subjects and Activities, therefore, Subjects and Activities should be interpreted as Subject types and Activity types. 4.3.2 BARBi (Nonvay) BARBi is a project initiated by the Norwegian construction industry to establish a reference data library with a complete collection of all concepts and objects from the building and construction industry with associated properties and relationships. The library will contain everything from complete constructions down to individual parts or products. Resources, activities and references to standards, classification tables and application protocols like IFC and STEP-APs (Standard for The Exchange ofProduct model data, Application Protocol) are included in the library. The Norwegian Building Research Institute has a central role in the development of the library and is working in

eWork and eBusisness in architecture, engineering and construction

552

close cooperation with Norwegian and international organisations involved with similar projects. BARBi is a conceptual, object-oriented, language neutral reference data library. It is the Norwegian version of a common reference data library based on the ISO DIS 12006– 3. BARBI is conceptual because it describes objects from what they are, independent of use and time, and not from what they are named or classified as. It is Object-oriented because it puts the object (concept) in the centre and studies its properties and relations to other objects. It is Language neutral because one object can have several names in the same language, one name can refer to several objects, and because what a dictionary gives as a translation of a word in one language not necessarily refers to the same object in another language. BARBi links standards, classification systems and their definitions. Every object (concept) in BARBi has a global unique Identifier. BARBi also provides multiple classification-and specialisation hierarchies for any concept. 4.4 The Semantic Web The Semantic Web is a vision for the future of the Web in which information is given explicit meaning, making it easier for machines to automatically process and integrate information available on the Web. A requirement for the Semantic Web is an ontology language that can formally describe the meaning of terminology used in Web documents. OWL has been designed to meet this need for a Web Ontology Language. OWL is part of the growing stack of W3C recommendations related to the Semantic Web in which OWL adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjointness), cardinality (e.g. “exactly one”), equality, richer typing of properties, characteristics of properties (e.g. symmetry), and enumerated classes. In OWL, an ontology is a set of definitions of classes and properties, and constraints on the way those classes and properties can be employed. An OWL ontology may include the following elements: (i) taxonomic relations among classes; (ii) datatype properties, descriptions of attributes of elements of classes; and (iii) instances of classes and instances of properties. 4.5 Standardisation efforts SPICE is an European project running together with the CEN/ISSS eConstruction workshop aiming at helping to promote “e-volution” in European Construction by providing an open discussion forum for consensus on several interrelated CEN Workshop Agreements (CWAs)—specifications needed for outworking of eConstruction. In recent years there has been a strong cooperation between committed industry players and the research community to create a climate of industrial interest and to encourage industrial uptake. Fundamental to this is the establishment of standards for eConstruction that application developers can implement to enable free flow of information between diverse software tools. Here is where the CEN/ISSS Workshop on eConstruction comes in, relying on the work carried out by some of the well-recognised European institutions in this field.

Setting up the open semantic

553

FUNSIEC is using the results produced by the CEN/ISSS eConstruction workshop since they are valuable ones. It is clear that the FUNSIEC approach is not about reinventing the wheel; rather it is really oriented to reuse and adopt/adapt what seems to be the best for helping the construction sector to be educated on use and development of SRs. 5 CURRENT STATUS OF THE PROJECT FUNSIEC project is in its very first phase. The state of the art analysis is about to finish, the specification of OSIECS is on the way to be started. This means that up to now only the foundations of the work were prepared; the long way run is still to come in the next period. The major steps to be taken are the creation of the FUNSIEC Semantic Experience Centre (FSEC), and the specification of the OSIECS infrastructure. The FSEC is an attempt to deploy a Web-based “experience centre” where practitioners can come to see and be “educated” about the potential application of semantic resources. The experience centre will use animations, films, and mock-ups, i.e., simple but talkative means. Complexity is out of scope of this action. The major guidelines supporting this action are the following: (i) simplicity: be presented in a very simple way, avoiding the “classical” fear created on people when discussing ontologies, meta-schemas, and related themes; (ii) state of the art: show the SRs currently available now in Europe; (iii) usage scenarios: show how the SRs can be used in the business; and (iv) business arguments: explain the benefits, gains, and advantages of using SRs. The OSIECS specification is essentially centred on defining semantic mappings among SRs on the one hand and on providing the required openness and flexibility to incorporate new SRs, on the other hand. FUNSIEC approach follows the “standard”. The OSIECS kernel is being developed based on the SRs previously mentioned. A preliminary evaluation of the meta-schemas supporting each one of the SRs has been conducted. A common meta-schema is to be designed, exploiting the best features found on those meta-schemas. The specific richness of the ISO 12006–3 is to be combined with the flexibility offered by OWL. The content of the e-COGNOS ontology can be used as input. The simplicity of bcXML when creating and importing taxonomies cannot be neglected. Among the problems likely to be faced during the development of FUNSIEC project, it is important not to neglect or underestimate the effort required to promote and disseminate this initiative. The experience centre has to be known and used by the targeted audience, otherwise it becomes useless. The promotion of the OSIECS infrastructure will also require more effort than its development, for sure. On the technical side of the (e)story, dealing with meaning is a very demanding challenge, especially when proposing any sort of “reference” for a given domain. Meaning is, sometimes, strongly related to the “eyes of the observer”. There are good results available now over the matter “semantic mappings” and FUNSIEC will capitalise on them. FUNSIEC believes that it is possible to combine the best features of the existing solutions and produce a good reference with OSIECS.

eWork and eBusisness in architecture, engineering and construction

554

6 CONCLUSIONS AND WORK TO BE DONE The FUNSIEC project is a small but very ambitious one. Tackling the “meaning of things” and education of the practitioners in a sector that has historically rejected this sort of initiatives is quite a challenge. However, the business aspect of the process is a very motivating factor per se. The technical side of the project is a very challenging one, but the business one is even more so, still knowing in advance that the semantic mappings will pose serious problems in the development of OSIECS. Promotion, dissemination, reach visibility of FUNSIEC within the sector is the major challenge on the long way towards the education of construction organisation over SRs. Education, in the largest possible sense, is the key factor in the FUNSIEC quest. Education requires having the right material to hand, the appropriate dissemination channels, and well-formed “preachers” capable to demonstrate categorically the real benefits and gains of standardised resources. Last but not least, a board of Evaluators is put in place bringing together researchers from Spain, Netherlands, England, and Canada, all of them involved with “semantic matters” and in a position to assess and help developing the project in the best possible way. ACKNOWLEDGEMENTS The authors would like to thank the FUNSIEC consortium for their contributions as well as the financial support from the European Commission under the eContent programme. REFERENCES CEN, 2003. CEN/ISSS Roadmap for addressing key eBusiness standards issues 2003–2005, Source: CEN/ISSS eBusiness Standards Focus Group, available at http://www.eeuropestandards.org/Docs/Roadmap.pdf. Tolman F., Bohms M., Lima C., van Rees R., Fleuren J. and Stephens J., 2001. eConstruct: expectations, solutions and results, ITcon Vol. 6, Special Issue Information and Communication Technology Advances in the European Construction Industry, pp. 175–197. Lima C., Fies B., Zarli A., El Diraby T. and Lefrancois G., 2003. Using ontologies to support a KM solution targeting the Construction industry, CE2003, Madeira, Portugal, July 2003. CWA3, 2004. European eConstruction Meta-Schema (EeM), CEN/ISSS eConstruction Workshop. Wostneck K., 2003. Classification, Taxonomy, Ontology, what do we mean with it? In: 10TH ISPE 2003, 2003, Funchal. International Conference on Concurrent Engineering: Research and Applications. 2003. eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Practical use of the semantic web: lessons learned and opportunities found R.V.Rees, W.V.Vegchel & F.Tolman Faculty ofdvil Engineering and Geosciences, Technical University Delft, The Netherlands ABSTRACT: This paper describes an early application of the semantic web, the lessons learned, and the research done afterwards on elements needing improvement. The scenario focused on private house owners that want a contractor to build an extension to their home for an enlargement of their living room. In the typical case, the client does not use the services of an architect, but deals with the contractor directly, The client’s perception problems and lack of building knowledge are a severe handicap in his dealing with the contractor and in his ability to communicate in a clear way the desired outcome. The research question was: “Is it possible to realise adequate support for this category of clients over the Internet?” Semantic web technologies were used in an effort to build a prototype application to support the client. The semantic web supports linking an item in one semantic web file directly to an item in another file, so this mechanism was used to try out a number of separate co-operating ontologies instead of the usual single large ontology. In the last stage, to test out the integration with existing systems, the data describing the living room extension was coupled with two existing classifications, one for specifications and one for costing. After the initial prototype, an evaluation was made. The tools used in the process were evaluated. The idea of utilising multiple co-operating ontologies worked well. Combining the data with existing classification systems was straightforward and fits in well with the overall semantic web system. Creating the content of the example ontologies, however, was an unsatisfactory part of the prototype development. Directly usable ontologies were not available, most were restricted to existing classifications or were small test ontologies. The most pressing problem was unclear separation between the functional and the technical viewpoint and their relation to the part-of problem. In the final research the focus became the content of the ontologies and especially the functional/technical distinction. The second focus was the extension of the prototype towards the automatic generation of a building specification in a web services setting. The aim was to provide insight in the applicability of the semantic web regarding knowledge-oriented tasks.

eWork and eBusisness in architecture, engineering and construction

556

1 INTRODUCTION Meaningful (semantic) electronic communication in Building and Civil Engineering has been researched for many years. Success has been limited however. The bottleneck was the time-to-market of the standard itself. ISO-STEP produced paper-based standards that first had to be implemented by the application vendors before end-users could profit. AIA-IFC shortened the cycle somewhat, but at the cost of speeding up the number of new releases. With the arrival of XML a new approach became feasible. The European eConstruct project developed bcXML as an example of a web-based communication language for Building and Construction. With the newest OWL/RDF technology many problems disappear that eConstruct could not solve at the time. It seems that electronic meaningful communication is finally entering the arena ready to change Building Construction into a truly modern industry. At least that might be the case if the Semantic Web delivers what it promises. 2 TERMINOLOGY BASELINE To set a baseline for this paper, we will first introduce the semantic web and shortly explain what we mean with “ontology” and “classification”.

Figure 1. Visualisation of RDF data. 2.1 RDF: the semantic web’s data model The difference between the web and the semantic web is: • Web: links from web page to web page. • Semantic web: links from individual data item to individual data item, even when placed in a different file. URLs used as globally unique id for identifying data items. The links themselves are also classified with an URL. http://example.org/ont/Door (resource): http://example.org/ont/height (property)=“2.40” (value). Values can themselves be resources, like in http://example.org/ont/Door (resource): http://example.org/ont/material (property)=http://example.org/ont/ Wood (resource used as value).

Practical use of the semantic

557

RDF sees everything as resource-property-value triples also named subject-predicateobject. When reading multiple files, an RDF application combines all data into one set of triples, so that data items with the same URL in both files are internally seen as one. This means that the information in the files is combined, making it feasible to have dispersed information that can later be combined. Also you can extend other semantic web files, for instance you can add your own extra levels to an existing classification system. 2.2 Ontology and classification Both the term ontology and classification will be used in this paper. As discussed in (Rees 2003), these terms can be used to indicate multiple things, partly over-lapping. The semantics suggested in that paper for classification: Classification or “simple classification”. A grouping of entities according to some external criteria. The grouping will be quite natural, as it is mostly made from a certain viewpoint. Classification is basically a set of boxes (with labels) to sort things into. It can be used as a user-friendly view on/in a taxonomy or ontology Likewise for ontology: Ontology is a set of well-defined concepts describing a specific domain. The concepts are defined using an subclass hierarchy, by assigning and defining properties and by defining relationships between the concepts etcetera. When using the term “ontology” an indication should be given of the kind of ontology. A very simple ontology could perhaps better be named “taxonomy”, but a heavyweight ontology should specify and advertise its capabilities lest it be grouped with the apparent majority of very lightweight ontologies. An ontology’s goal is to provide a common, reference-able set of concepts for use in communication. It is quite common to use multiple ontologies, each providing concepts for a particular domain, together forming a rich vocabulary for communication. The intended semantics of ontology is a set of identifiable classes, placed at least partly in a subclass hierarchy, with labels and possibly descriptions, with associated properties. 2.3 OWL: the semantic web’s ontology formal RDF makes it possible to identify and relate data items. This by itself is not enough. What is needed is to make the semantics of the data items explicit. An ontology can be used to define classes and to provide a list of properties associated with those classes. Besides being a standardised (Owl 2004) web format for ontologies, OWL also allows a limited amount of reasoning. The semantics of the OWL model elements are welldefined, which is a necessary prerequisite for reasoning. When a certain property (say “door_height”) is defined as being only allowed on a certain class (say “door_leaf”), any object that has that property can be deducted as being part of that class. When needed, this allows you to define class A as being the same as class B, but excluding those objects that have property C. In practice, you can for instance exclude objects from being a member of the class “load bearing walls” if they are not connected to another supporting load bearing

eWork and eBusisness in architecture, engineering and construction

558

structural element, like a foundation. This way you can detect possible failures—on the condition, of course, that the ontologies and supporting applications are detailed enough. 3 IMPLEMENTATION OF A SEMANTIC WEB SCENARIO This section describes an implementation of a semantic web based prototype. Much of the work was done by graduate student Wouter van Vegchel (Vegchel 2004). 3.1 The scenario The business scenario was directed to private house owners who want to improve and extend their houses. Typically, no architect is involved in such a smallscale project. But that means that the house owner (the client) has much less relevant knowledge than the contractor. This inequality can lead to problems. 1 The client is unable to make his desires sufficiently clear to the contractor, leading to disappointments later in the process. 2 The client is unaware of a lot of possibilities, and learns about unknown technical solutions and alternatives during the project. 3 The client is unaware of a lot of risks, resulting in friction between the client and the contractor. The basic premise is that it is possible to support the private house owner with relevant computer-based knowledge. House owner associations typically have a lot of data on common risks. Identifying these risks beforehand allows you to prevent the risk or to agree on the risk beforehand with the contractor, for example. Providing the client in an early stage with multiple common alternatives for his wishes might mean more satisfaction because of a better fit between the solution and the wish. Ideally, a simple, but good, building specification can be generated that can form a basis for a better and clearer contract. The technical reason for this scenario was to provide a back to back walk-through of a complete semantic web enabled building information exchange. There are so many clients that have the same problem as our private house owner, though on a large scale. A small experiment to learn about the technology, its features, and its limitations seemed worthwhile. 3.2 The Ontology: basis for communication Obviously the semantic web was a pre-requisite for this research. Therefore definitions of objects used in the communication (house, extension, addition, foundation, roof, height, and so on) were made explicit in an on-line ontology. As the Building Construction industry is strongly fragmented, instead of developing a single huge ontology it seemed a good idea to create multiple smaller cooperating ontologies, each for a certain domain. Ultimately domain experts have to create the ontologies for their own domains. If

Practical use of the semantic

559

estimates are correct some 300.000 objects with properties and units should be described; clearly not a sma ll project. Using OWL this possibility is becoming a real alternative, as OWL allows the mixing of multiple ontologies. This is the semantic web in action: on the web you can link from one document to another, on the semantic web you can link from one data item in one location to one data item in another location. So a “mechanical ventilation system” can have a “subclassOf” link with a more generic “ventilation system” in another ontology. In the initial implementation a number small ontologies were created using Protege’s (Protege 2004) ezOWL (ezowl 2004) plug-in. The ezOWL plug-in

Figure 2. Example of the structure of the small ontologies. provides a graphical UML-like interface, but beyond a few dozen classes the display becomes overcrowded. The ontologies contained the modest ad-hoc needs for the prototype implementation. The top ontology described various types of private houses. This ontology used sub ontologies for Roofs, Walls, Foundations and such. For example the roof ontology described various alternative roofs the user can choose between. The roof system was broken down into great detail, i.e. down to side board and such. Protégé is a very powerful tool that already exists for a decade. Protege is extremely powerful as an information modeling tool, though basically only supports the subclass relation as object structuring mechanism. This scenario’s implementation added a limited part-of relation, as it was needed. Using Protégé, the main structure of the home extension ontology consisted of small two-level hierarchies. Each two-level hierarchy focused on a particular end-user choice. The subtypes were mainly technical solutions for a more generic concept. The more generic concept was often used as the target for either a relation or a part-of relation. The prototype was implemented for a simple extension at the back of the house. After making the required choices and filling in some properties for his project, a small instance model is available for the client.

eWork and eBusisness in architecture, engineering and construction

560

3.3 The customer support tool: generating a design With the concepts stored in the ontologies, a prototype web application was made that supported the client in his awareness and decision process. The main focus of the effort was to use as much as possible only the ontologies. The starting point, a house, is fixed. But the application retrieves the available subclasses of “House” and presents them as choices to the user. The selected class is then polled for attributes, which are presented to the user (flat or tilted roof, for instance). The design

Figure 3. Visualisation of a house with an extension. can be used as the basis for a visualisation (Figure 3) following the research of eConstruct (Rees et al. 2002) where VR shapes were generated as mark-ups from bcXML content files. It is fair to say that, though the user seemed to have a lot of choices, the set-up strongly resembled the principle introduced by Henri Ford (a T-Ford can be delivered in any colour, as long as it is black). 3.4 Knowledge modelling The next step was to look into the knowledge modelling capacity of OWL. OWL DL (Description Logic) strongly resembles its predecessor DAML/OIL (DAML OIL 2001). DAML/OIL has been around a couple of years and experience with description logic, or logic programming, is amply available.

Practical use of the semantic

561

As a test case the applicable rules in the building regulations have been added to the ontology. As these rules are simply of an if-then-else type OWL had no problem with them. In fact it seems that OWL DL and OWL Full provide a strong basis for this type of applications and opens up a whole new market for knowledge vendors (including R&D institutions). Though time became rather limited we looked into the possibility to check the designs against a knowledge base that contained knowledge to prevent construction errors. From what we did it seemed that this type of services can be nicely build on-top of the ontology network. As many other services spring to mind from costs, risks, to a multitude of analyses, the idea took shape that this might become a whole new way to market knowledge. 3.5 Coupling with specification systems: using the available data With the instance available, we made a coupling with the Dutch specification system. A problem is that the Dutch specification system does not support such small projects without an architect (it is both an implementation and a legal problem: there are two differing legal frameworks, one for small works like these and one for bigger works with architects, subcontractors, etc.). The work done is therefore just for test purposes.

eWork and eBusisness in architecture, engineering and construction

562

Figure 4. Specification generation. The starting point was a text-based specification which was converted into an XMLformatted file (just text conversion). That was transformed (using xslt) into two separate semantic web RDF files, one for the specification’s chapter structure and one for the actual specification items content.

Practical use of the semantic

563

The instance was an RDF file pointing to the concepts in the ontologies. A file was created that specified the mapping between concepts in the ontologies and specification items. For example, “House” is the starting point. The mapping file specifies that for the opening section of the specification, naming the project, the address and the description of the extension have to be extracted from the instance. This mapping was, of course, done in RDF. The mapping used both “push” and “pull”. The specification “pulls” the info needed in the opening section (the house’s address, the extension description) from the instance. But it just reacts (“push”) on a lot of other items. It only includes a section on brick walls when the instance “pushes” the brick wall to the mapper. In a way, this simple solution mimics XSLT’s behaviour. The result is an RDF file with just the specification items, but without a chapter structure. A small program adds the relevant chapters from the separate chapter RDF file, generated previously. This is converted to HTML at the end. An interesting addition to this process was the conversion of the Dutch SfB classification table (nl-SfB, “elementenmethode”) to a similar chapter structure and adding the links from these chapters to the specification items. Without changing anything in the original data, this second chapter structure could be combined with the resulting specification items and transformed to HTML as an alternative building specification. To be more accurate, the first specification structure is a work breakdown structure, which is the structure of the Dutch building specifications. The second classification (nlSfB) is normally used (in the Netherlands) for costing applications and CAD drawing layering. As a side note, work is underway to make the nl-Sf B an alternative for the work break-down classification in the building specifications. 4 DISCUSSION ON THE IMPLEMENTATION AND FURTHER RESEARCH 4.1 The basic scenario as a whole Storing the base data in ontologies worked well. Both the support application and the specification generator could use it as a basis for communication. The possibility of subclassing (inheritance) was used well by both applications. The client support application displayed different kinds of houses (subclasses of “House”), the specification generator needed a “House” instance as a starting point, but reacted also perfectly to an instance of a subclass. This might not seem like a big deal, but there are not many current applications that have such a thing build-in. The real support of the client by warning him for common pitfalls etc., was not undertaken because of time constraints. In this way, only the generation of a simple specification as a basis for a contract provides a bit of support. On the other hand, the ontologies contained common solutions for house extensions, preventing possible omissions. Regarding further work on the instance model, the next stage is obvious: a real interaction with CAD-based data. The only currently realistic option is IFC. When

eWork and eBusisness in architecture, engineering and construction

564

looking at a semantic web supported scenario, it makes sense to use ifcXML. As a baseline, ifcXML files should be downloadable on the Internet, but it makes a lot of sense to expose the normal IFC data store fUnctionality on the Internet. http://example.com/building42/2nd_floor could return an ifcXML file with all elements on the second floor, http://example.com/building42/doors could return all doors in the model. 4.2 Ontology development The ontologies created were ad-hoc. The only objective was to support the selection of alternative technical solutions. The small modelling needs of the case study provided the classes for the ontologies. 4.2.1 Ontology sources The problem is that there are no ready-made ontologies available. With “ontology” we mean basically a set of classes and attributes. There are a few projects aiming at creating such an ontology and there are a few starting points for ontology developments. *0 12006–3: LexiCon, Barbi, SDC. (Includes eConstruct’s taxonomy, as it was LexiCon-based). No definitive, usable results are available yet. *1 12006–2: SfB-like system, but mainly a basis for classification systems. The objective is to harmonise national and regional classification systems. The (inter-)national SfB variants have tables with useful classes, but they are not coupled with attributes. Those tables can be a good starting point, though. Classification systems are cornerstones in ontologies as they summarise and organise existing knowledge (Ekholm 2004). *2 E-cognos ontology: mainly collection of existing classification systems (BS6100, Uniclass), so missing attributes. *3 IFC has both classes and attributes (property sets), but separated from the standard. The choice of classes and attributes and their definitions is in first instance based on object oriented CAD packages (broadly spoken). It is a limited set, but the reasonably widespread use of IFC and the attractiveness of a coupling with a CAD system make it a good candidate for inclusion or coupling. TNO (the Netherlands) has extracted the classes and property sets as an OWL file. The XM7 project harmonises 12006–3 with IFC.

A more detailed discussion can be found in CWA4 (CEN Workshop Agreement), available at http://www.nen.nl/wseconstruction. 4.2.2 Ontological business needs For ontologies to be created and used, they have to fulfill real business needs. The two places in the construction process where money can be seen most readily are the following: • Procurement: searching, buying and selling of construction materials. • Selection of technical solutions for designed objects; the coupling of a design or designed elements with a contractor’s offering or possible technical solutions.

Practical use of the semantic

565

On a higher level, both can be seen as a matching process between supply and demand. Objects and properties can be viewed from a functional perspective (demand) and a technical perspective (offering, supply). Functional objects have functional attributes, or better, functional requirements. Unless the client demands a specific object, the demand specification will normally be phrased with functional requirements. An example is provided below. A technical object or, technical solution is a specific object like a brick wall. In between the functional demand specification and the possible technical solutions there ought to be a matching process. The functional objects in the ontology should therefore be specific enough to allow suppliers to automate the matching process of those fimctional objects with their products. 4.2.3 Some implications Ontologies can perhaps best be seen as basic pieces of infrastructure, the costs of which should be shared. Non-proprietary and a shared workload: open source. If the advantages of generally available ontologies are realistic enough, investing in coordination, some infrastructure and the man-hours needed to fill the ontologies should be possible. In other (richer) industries like the medical industry huge ontology building efforts are taking place. Their ontology web, UMLS is said to contain over 700.000 objects. The advantage of ontology based information and knowledge sharing are obvious: a priori integration (if based on the same ontology, applications can communicate) instead of the commonly used a posteriori integration. It seems that in Building Construction the government has a large stake in the development effort (provided that the results are open and given enough momentum market forces can take over) because there is so much at stake and so much tax payer money spoiled each year. 4.2.4 Future work The approach followed in the presented research, combined with the indicated demand/supply direction, gives us a few very interesting research topics. First ontologies: The functional unit/technical solution FU/TS paradigm proposed in the General AEC Reference Model GARM (Gielingh 1988) seems useful, but it needs to be tested with a sizeable set of data. This directly draws attention to the part-of relation semantics. Taking just eConstruct’s ontology as example, it was never clarified whether the parts indicated in the ontology were a definitive list or just a suggested list of common parts, or a set of obligatory parts. FU/TS includes the decomposition of a technical solution into a few smaller functional units and so could be a good basis for a clarification. The ISO standard 12006–2 is partly ftmctional-based, partly technicalbased, so this common classification needs attention.

eWork and eBusisness in architecture, engineering and construction

566

Figure 5. Prototype web-based functional unit/technical solution editor. A second subject of interest regarding ontologies is the specialisation hierarchy. This mechanism is very useful, especially for data reduction. From a scientific viewpoint it is interesting to try to combine the specialisation hierarchy with FU/TS decomposition using multiple, smaller, ontologies as shown in this research. A third challenge is to get an open source like ontology development off the ground. This needs a good web-based interface for cooperative ontology development and a good,

Practical use of the semantic

567

clear license. Preliminary think work suggests that a “creative commons” license (http://www.creativecommons.org/) might be a good choice. 4.3 Web services This section provides a view on the possibilities of web services. Information from several sources, available in web-readable formats, is combined into a new result. The actual implementation of the client support application is independent from the specification generation, as only the readable result that is transferred over the Internet matters. Note that in this case we only transfer files (XML, RDF) using the normal Internet protocols (HTTP), we are not defining a custom SOAP API for every application that has to be implemented by the other applications. It is recommended to not use SOAP unless absolutely necessary. SOAP raises the coordination costs with the num ber of attached applications. For each different application (identified by an address) you need another API. HTTP is always the same, so more applications do not raise the coordination costs, apart from the extra addresses (naturally). 4.4 Semantic web as knowledge support A other interesting area of research is to look beyond the obvious advantages of semantic web based ontologies. The obvious part is having easily usable object and property definitions. The less obvious part is the built-in support for knowledge support. OWL supports a basic level of reasoning. It allows you to define classes as the set of objects fulfilling a set of criteria. A certain class of houses can be defined as having an internal sound level that is lower than a certain value. Existing houses (or designed houses) can than be tested if they are part of that class. This allows an integrated handling of some types of regulations. Likewise, regulations can define a certain class of doors to have a minimum width (for safety reasons). A public building can require all doors to be part of that safety class. 5 CONCLUSIONS A common network of object definitions (including properties and units) first should satisfy the needs of the national industry. This has been one of the lessons learned from the European eConstruct project where endless discussions about the nature of very common objects (like inner doors) proved beyond reasonable doubt that different concepts are applied in different European countries. French inner doors differ from Dutch inner doors and German inner doors. The same is true for most objects, large and small. Standardisation efforts of data describing Building Construction object definitions should realise this fact. Only after each country has defined its own objects, European or even ISO standardisation comes into play. The case study presented above clearly confirmed that conclusion. Everything contained in the ontology is coloured by national

eWork and eBusisness in architecture, engineering and construction

568

regulations: the type of houses, the type of extensions, the type of walls, foundations and roofs, the details of the constructions, everything. Interesting is that the purpose of the ontology reflects in its structure. Supporting the client in his decision making process makes it mandatory to distinguish between a functional view and a technical view. In the small this has been implemented and demonstrated. How it should be done for large projects is a question for the future. Also rather interesting is that ontology-based web services might well change the future of software and service providers. Ideally web services should be implemented as Virtual Experts. Paying only for the time the service is actually being consumed and not for the availability of the applications seems quite interesting for the clients, though maybe somewhat fearfiil for the vendors or their service staff (vendors only have to support one version of their software!!). The case study learned that it might well be possible to develop support for all kinds of knowledge-rich services like cost analysis, risk analysis, specification, feasibility, maintainability, and much more, and make that support available on every PC over the Internet. Also interesting is the possibility that new players may enter the market. R&D institutions can transfer results of research into usable services instead of new regulations, for example to provide knowledge intensive services, such as analysing designs for possible design errors, or transaction risks. All in all the case study proved to be useful. The semantic web brings challenging opportunities for improved information and knowledge sharing which, in time, will change Building-Construction as we know it into an industry that intensively co-operates to truly fulfill the clients’ demands. REFERENCES DAML/OIL 2001. Reference description of the DAML+OIL (March 2001) ontology markup language. Available on-line at http://www.daml.org/2001/03/ reference Ekholm, A. 2004. ISO 12006–2 and IFC—could they be harmonized? Unpublished, w78 workshop Toronto 2004. Ezowl 2004. Visual semantic web ontology editor. Available on-line at http://iweb.etri.re.kr/ezowl/ Gielingh, W.F. 1988. General AEC reference model (GARM). Delft: TNO bouw. OWL 2004. OWL Web Ontology Language Reference. Available on-line at http://www.w3.org/TR/2004/REC-owl-ref-20040210/ Protege 2004. Protege ontology editor. Available on-line at http://protege.stanford.edu/ Rees, R.van, Behesthi, R., Tolman, F. 2002. bcXML enabled VR project information front-ends. Ework and ebusiness in architecture, engineering and construction. Lisse: Balkema Rees, R. van 2003. Clarity in the Usage of the Terms Ontology, Taxonomy and Classification. Proceedings of the 2003 cib w 78 conference. Auckland. Available on-line at http://vanrees.org/phd/Cib78ConferencePaper2003 Veghel, W. van 2004. Het bouwportaal. (Note: master thesis in Dutch). Available on-line at http://www.woutervanvegchel.com/afstuderen/BouwPortaalFinal.pdf eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Supporting ontology management through self-describing concepts T.E.El-Diraby Assistant Professor & Director, Dept. of Civil Engineering, University of Toronto, Canada ABSTRACT: Lately, several research projects developed more coherent hierarchies, in the form of taxonomies (e-construct project and eCOGNOS project, for example). However, there is a need to bridge the gap between these taxonomies, wrap legacy classification systems, and link the construction industry to other industries. i.e. we need to develop formal clustering mechanisms to allow these (and future) taxonomies to interoperate. This paper presents an architecture for clustering construction concepts. The proposed architecture clusters construction concepts into two main dimensions. The first: Practical Concepts, encapsulates the main entities in construction terms (such as Process, Actor, Resource and Products). The second: Clustering concepts, is meant to capture the attributes, types and constraints of entities. Using genetic algorithms, each concept will carry within itself full reference to its attributes, constraints and other related concepts. Such self-describing concept representation is in valuable in data mining exercise, where formal concept analysis (FCA) and genetic analysis techniques could be used to automatically generate construction taxonomies and/or concept lattice. The clustering concepts are based on the basic IDEFO dimensions (input, output, mechanisms and controls). As such they contain metadata about concepts. This will allow other industries taxonomies to access concept in any taxonomy based on the proposed architecture.

1 INTRODUCTION An ever-existing theme/concern during the development of any ontology is the clustering of industry concepts in a flexible and meaningful manner. Clustering is the task of dividing a knowledge domain into coherent subsets of classes (or concepts) that share a common thread (use, meaning, origin, etc.). Classification refers to methods and algorithms for placing (or classifying) concepts in relevant clusters. Both tasks are “illdefined, non-deterministic task, in the sense that, using only the training data [initial concept pool], one cannot be sure that a discovered classification [or clustering] rule will have a high predictive accuracy on the test set, which contains data instances unseen during training (Freitas, 2002).” The development of clustering mechanism is the cornerstone for taxonomy development. It is inherently an exercise in the balance between the art and the science of doing so. Several advanced data mining techniques are available for automatically discovering common patterns in industry databases. Through Formal Concept Analysis

eWork and eBusisness in architecture, engineering and construction

570

(FCA) and advanced algorithms, these patterns could be used to create taxonomies. The complete reliance on data mining tools cannot produce a usable taxonomy. This has to be balanced with human interference to assure practical analysis and modeling of industry fundamental concepts. Several attempts have been made for developing concept clusters in the construction domain. Most of these have followed a top-down modeling approach, i.e. through dependence on human knowledge, a group of researchers using different modeling tools (IDEFO, EXPRESS, UML) have created several cluster structures for construction concepts. This is very suitable for an industry with ill-defined data structures like the construction industry The overwhelming portion of these clustering mechanisms was in the form of classification systems (Masterformat, UniClass, BS6100, for example). Most of these classification systems are rich in industry-friendly terms. However, their fundamental drawback are in their structured (in contrast to object oriented) approach, their static nature, product-orientation, and the lack of coherent underlying clustering principles. In contrast, other industries, with well established databases, have relied on the bottom-up approach for establishing some of these taxonomies (Michalski and Stepp, 1983; Fisher and Langley, 1985; Fisher, 1987; Hull and King, 1987). The objective of this research is to develop a flexible scalable clustering mechanism for construction concepts that balances the industry need for practical terminology and the needs of automated machine-based concept mining. The research also aimed at using the clustering mechanisms to equip each concept with a full reference to its metadata (attributes, constraints and related concepts) in a manner that will allow a distributed agent-like environment where inter-industry concepts can interact in a virtual collaborative process. 2 RESEARCH SCOPE AND METHODOLOGY To develop an effective clustering (or taxonomy) architecture, we need to create a set of metadata (referred to here also as clustering concepts), which give us all a place to record what a document, or concept, is for or about. To achieve that, we need to establish a standard syntax, so metadata can be recognised as such; and one or more standard vocabularies, so search engines, producers and consumers all speak the same language when describing concepts. The proposed architecture clusters construction concepts into two main dimensions. The first: Practical Concepts, encapsulates the main entities in the construction industry (Project, Process, Actor, Resource and Product). The second: Clustering concepts, are meant to capture the attributes, types and constraints of these entities. Each concept is then represented as a gene that will carry within itself full reference to its metadata (parameters, domain, attributes, constraints, etc.). Concepts, acting as agents, can enquire about other concepts’ domain of application, constraints, attributes, etc. Such self-describing concept representation is also invaluable in machine-based knowledge/pattern discovery, where FCA and other data mining techniques could be used to automatically generate construction taxonomies and/or concept lattice.

Supporting ontology management

571

To achieve that, the research first identified a set of motivating examples describing an industry need or situation. These were represented in the form of use-cases. A set of industry needs were then developed to guide the development of the clustering architecture in parallel with an extensive literature reviews of clustering methods/ontology/knowledge management/data mining/lattice theory. The research project, which spanned 3 years, then developed a set of taxonomies for several industry domains (highways, telecommunications, buildings, sustainable infrastructure systems, project finance, and land development). These taxonomies were built on the same lines of the e-COGNOS taxonomy. Overall, these taxonomies encompass about 15,000 unique concepts. Iterative revisions of these taxonomies were conducted over time. Throughout the development, 36 industry experts were involved in one-on-one interviews to assess the validity of these taxonomies. Analysis of recursive industry input led to the development of a top-down model for the clustering architecture. i.e. a model that is dependent on researchers’ and industry views of construction concepts. In other words, the base architecture did not depend on a data mining approach (which is referred to hereinafter as bottom up approach). This is mainly due to concerns for external validity (Cook and Campbell, 1979). External validity refers to the reusability and ease of application of a system. 3 TOP-DOWN APPROACH: ENTITY MODELING This research contribution is in the creation of a top-down clustering scheme that could help future bottom-up discovery of construction taxonomies (through data mining techniques). The research developed an extended model of IDEFO. It includes an extended semantic description of its four dimensions: Input, Output, Controls and Mechanisms. Furthermore, the research attempted to generalize the use of these four dimensions beyond Process to secure more comprehensive representation of Actors and Products. The research project has developed a generic mechanism to extend the use of these four dimensions to the e-COGNOS Entity. An Entity is a Project, a Process, a Product, an Actor or a Resource. Figure 1 shows the extended IDEFO representation of Entity: • Controls: represent an umbrella for all Laws, Code, Specifications, User requirements, Conditions (such as Site restrictions, Topography, Weather) and other controls like Cultural and Environmental requirements. • Mechanisms: have been defined to include: – Theoretical dimension: this is a fundamental mechanism that helps us formalize a metaphorical model for analyzing a problem, a process, a product, etc. This include: ○ Theories: such as the Theory of Structures and the Theory of Architecture. ○ Algorithms: such as Clustering Algorithms and Genetic Algorithms. ○ Principals: such as the Least Energy Principle. ○ Strategies: where formal theoretical representations are not available, strategies represent the fundamental mechanism that supports the handling of our work.

eWork and eBusisness in architecture, engineering and construction

572

As an example, one can think of the different impacts of adopting a Sustainable Strategy Vs. Traditional Strategy. In addition, Company Strategy is a major tool in shaping most of its processes. ○ Best Practice: at lower levels of our work, best practices are one important tool in forming a model of our work entities.

Figure 1. Extended IDEFO model. – Abstract Concepts: concepts like Motive (of a human being), optimization (of Process), usability (of a software), Team Spirit, Scalability (of a system) and the Ecological Footprint (of a Product) are some of the most fundamental elements/mechanisms that we use in forming/ modeling our Entities. – Parameters: in contrast to the Abstract Concepts, which are fuzzy and generic, Parameters are crisp formal/mathematical elements that contribute directly to a Theory or an Algorithm. For example, Bending Moment and Load (relevant to the Structural Analysis Theory). – Attributes: in contrast to Parameters, which are dedicated to describing another mechanism (Theories and Algorithms), Attributes are dedicated to the description of Entity features. These could be indigenous features such as the Skill (of labourer) or exogenous (assigned) such as Schedule (that is assigned to a Project), Objectives (of a Project or a Process). – Technologies: these are the tools that help us perform our work based on the Theoretical metaphor that was built for each Entity (Process, Product, Resource, etc.) and on the desired attribute of such work. This includes Methods such as the Management by Objective Method (for managing a Project), Techniques such as the Lift Slab technique, and Best Practice such as the “Best Practice #n in motivating Labour”.

Supporting ontology management

573

– Measures: After theorizing a metaphor for Entities, modeling their aspects using Abstract Concepts and Parameters, specifying their attributes, and using some Techniques for executing them, we have to measure the conformance of the output to our objectives. This includes conducting Tests (for physical Entities) and using Metrics (for the logical and tacit Entities). • Input and Output: this defines the input and outputs of Processes. It is also applicable, to an extent, to Actors (Inputs and outputs of an organization) and Projects. It can be immediately noticed that this is not the only way to cluster construction concepts. The definitions used are also not universal. “Since the classification task is studied in many different disciplines, there is a wide variety of terminology in use to describe the basic elements of this task. For example, a data instance [in data mining domain] can be called an example, an object, a case, a record, or a tuple. An attribute can be called a variable or a feature (Freitas, 2002).” Another important note that can be observed is the need for developing means for capturing the polymorphic nature of our concepts through what could be called “typedevelopment”, i.e. we need consistent ways to drive flavours of Entities from an abstract Entity (Steimann, 2000). For example, Safety Code, Accounting Code, Zoning Code, National Code, Provincial Code, Municipal Code, are flavours of Code derived along the dimensions: Domain (for Safety, Accounting, and Zoning) and the Setting dimension (Local, Provincial/Sate, National/Federal). Agreeing on unified sorting/clustering dimensions will enable consistent generation of concept flavours. It can also be further noted that, due to the multidimensional nature of our concepts, any clustering mechanism has to allow for multiple inheritance. For example, “Best Practice” can be a Theoretical tool that supports the design of a product. It can also be an execution Technique for a process. 4 BASE CLUSTERING ARCHITECTURE Figure 2 represent a clustering framework proposed by this research. The framework used two main dimensions to cluster knowledge: Practical concepts and Clustering concepts. The practical concepts encompass the Entity concept and some Basic concepts. The Clustering concepts encompass the extended IDEFO model discussed above and type-development mechanism. The Horizontal dimension in Figure 2 shows the main types of Entities in Construction: Projects, Processes, Products, Actors, Resources. The Vertical dimension shows the clustering concepts or metadata used to describe these entities. The mechanism, controls, inputs and outputs related to these entities are shown in the lower part of the vertical dimension. The upper portion shows the types of these entities. Systematically, the clustering concepts are used to develop types and sub elements of the practical concepts. They also could be used to link related attributes/constraints/mechanisms to their relevant entities. As can be seen in Figure 2, this allows an out-of-domain taxonomy (Operations Research taxonomy for example) to be easily integrated in a construction taxonomy (items in the construction taxonomy will refer to operations research terms as their mechanisms or theories, etc.). Similarly, a

eWork and eBusisness in architecture, engineering and construction

574

taxonomy for sustainability or even engineering design could be easily blended into the main taxonomy.

Figure 2. Proposed clustering architecture. 4.1 Type-ing metadata The proposed clustering framework identified a set of features that could be used to generate concept types in a consistent manner. These include: • Setting: Mainly Local Vs. National Vs. International. For example, a National Code is a type of code, a Local Authority is a type of actor and so forth. • Style: This is used to define flavours of concepts. For example, Green Filed Project Vs. Brown Field Project, a Sustainable Resource Vs. Non-Sustainable Resource. • Domain: This is used to develop domain-oriented types. Different from traditional clustering techniques (prevalent in data mining), the proposed framework allows for multiple inheritance. For example, the Structural Design Process belongs to the Design domain, the Structural Analysis domain, which is a subtype of the Engineering domain. Also, a Design Process is subtype of the Process Concept that belongs to the Design domain. Similarly, a Planning Process belongs to the Planning Domain. Figure 5 shows an outline of the overlapping domains proposed by this framework. 4.2 Sub-ing metadata

Supporting ontology management

575

• Whole-Part sub-ing: The first obvious sub-ing mechanism is the traditional whole-part relationship. For example, in Figure 2, a Project can be divided into several contracts. • Phase-ing: Processes and Products have life cycles that span several phases. It is proposed that four generic phases be used to express the timeline of Entities: conceptualization, planning, execution and utilization. Figure 3 shows a sample Phaseing of some construction processes. The self explanatory Figure 4 shows an amended e-COGNOS taxonomy that is based on this clustering architecture. 5 CONCEPT GENES: SELF-DESCRIBING CONCEPTS It is proposed that each Practical Concept carries in its definition a reference to its Clustering Concepts, hence providing a genetic signature for each concept. Figure 5 shows a self describing concept in the form of a gene. It includes a unique Name and an ID that are relevant to a certain domain or an industry. It also includes a reference to other synonyms. It also includes a reference to the mechanisms used in its operation (if any), any input, output and controls. For example, the gene for a Civil Design Process could include a reference to the Theory of Structures, Structural Engineer, Structural Design and Structural Code. In contrast, the gene for a Mechanical Design

Figure 3. Phas-ing metadata.

eWork and eBusisness in architecture, engineering and construction

Figure 4. Amended e-COGNOS taxonomy.

Figure 5. Self describing concepts.

576

Supporting ontology management

577

Process could include a reference to Thermodynamic Principles, Mechanical Engineer, Mechanical Design and Thermodynamics/mechanical code. Furthermore, the gene could also carry reference to some hedges defining its type and genre. For example, it could include reference to which domain does it belong and its membership in such domain. For example, a Value Analysis Process belongs with a 100% membership to Project Planning/Scoping domain and with, say, 60% to the Project Management domain and with 40% to the Constructability domain. A Design Process could be controlled with a 100% membership by the Local Code and with a 90% membership by the National Code. If the membership of a process into the Virtual Domain is 100%, then it would, automatically, be “type-ed” a Virtual Process. If on the other hand, the membership is 0%, then it is a traditional Process. If the membership is somewhere in between, then it’s a partially virtual process. A full concept gene would include a membership value respective to each clustering concept. A partially described gene would just include those clustering concepts that have a membership of, say 60% or more. More importantly, one concept could have in its input filed a reference to another concept. For example, in Figure 5, concept #33 is occupying the “input” field. A search engine could also categorize concepts based on their metadata. For example, in Figure 5, concept #1 and #33 are both of the same style (virtual). This allows for easy establishment of a causal relationship between the two concepts in a collaborative process. 6 BOTTOM-UP APPROACH: AUTOMATION OF CONCEPT AND PATTERN DISCOVERY The top-down modeling approach includes only a partial subset of all possible concepts. This is due to the always limited time for taxonomy development, the limited knowledge of the modeling team, the normally limited scope of the taxonomy projects (no one project will, in deed should, attempt to cover every concept in our lives. As such, it is certain that the end user (especially those who are at the boarders of the taxonomy scope) will need to use concepts that are beyond the training set which the Top-Down approach has used. This reduces the coverage of such models, produce inflexibility in discovering and allocating new concepts (that were not known during the modeling time). Upon retrieving data in a data mining exercise or during a web search, this could reduce the system efficiency. The solution to these problems has been always in the use of a Bottom-Up approach for concept definitions. Normally, this is done through data mining techniques such as Formal Concept Analysis (FCA). In this approach, a set of relevant documents (or knowledge items) are queried to detect concepts clusters and their interrelationships. The result is a concept lattice that could include some artificial concepts (non user friendly concepts) that is, however, very important for automated knowledge retrieval.

eWork and eBusisness in architecture, engineering and construction

578

7 FORMAL CONCEPT ANALYSIS & LATTICE ALGEBRA FCA defines a formal concept C as a triple (E, I, R). E (extent) and I (intent) are two sets and R is a relation on Ex I. The elements of E are called formal objects and the elements of I are called formal attributes. eRi is a relationship and is read “formal object g has the formal attribute i”. A formal context is a table whose raw(s) are formal objects, columns are formal attribute, and cell values are fo rmal relationships (Haav, 2003). For example, Table 1 shows a simple formal context. In this context, an infrastructure product is either a bridge, a telecom duct or a water pipe (all of these are formal objects. i.e. they belong to E). The attributes of these objects, in this context, are above ground, underground, privatized or non-privatized (all of these belong to I). Figure 6a shows the concept lattice resulting from applying FCA to this context. It can be seen that the lattice does not include the main objects only ( bridge, telecom duct and water pipe) but that a set of intermediately concepts have been created to describe the “intent of these objects”. For example, we see a concept like “non-privatized underground infrastructure products”. If we assume that latter on Bridges can be privatized, then a concept called “privatized above ground infrastructure will be created” shown in dotted lines in Figure 6a. FCA is a key tool in developing lattice. Representing our concepts in the form of a lattice is quite important to machine learning as it allows full use of lattice algebra. In the context above, the set of all common attributes of a set of formal objects A (subset of E) is denoted as eA. For example, e{telecom duct}= {underground, privatized, nonprivatized} and e{water

Table 1. Infrastructure products. Above ground systems

Underground systems

Privatized assets

X

X

Nonprivatized assets

Infrastructure product Bridge

X

system Telecomm system Water systems

X

X

Supporting ontology management

579

Figure 6. Lattice algebra. pipe)={underground, non-privatized}. The set of all formal concepts that posses a certain attribute B (sub-set of I) is denoted iB. For example, i{non-privatized}={telecom Duct, waterpipe}. The pair (A, B) is called a formal concept if A=iB and B=eA. For a formal concept (A, B), A is called the extent of the concept. B is called the intent of the concept. In our example, ({Non privatized Under-ground infrastructure, telecom duct, water pipe}, {Nonprivatized Assets}) is a formal concept. Having concepts represented as lattice is a key factor in machine-based mining through lattice algebra. For example, if we use the binary operators+for supremum and x for infimum and using the formal context in Table 1, we can deduct the following rules: • Infrastructure Product=Above ground systems+ underground systems • Telecom Ducts=Privatized Assets×Non-rivatizedAssets

eWork and eBusisness in architecture, engineering and construction

580

• Above ground systems×privatizedAssets=Null • Privatized underground infrastructures×Water pipe=Null Such straightforward generation of rules is invaluable in document retrieval and web mining domains. 8 DYNAMIC ONTOLOGY MATCHING One main advantage of the proposed framework is the creation of “clustering metaconcepts”. It allows for describing what the concept is all about (in a similar way to metadata). This will allow for more dynamic cross-domain integration in an objectoriented approach. For example, by defining Algorithms as main element in Mechanism domain, the framework allows a specialist in Operations Research to develop a taxonomy of all Operations Research algorithms and plug them under this “metaconcept” into their proper place in this framework (see Figure 2). In other words, these metaconcepts represent a pointer to other domains or taxonomies. Similarly, if an expert develops a taxonomy for Sustainability, it can be plugged into the framework through proper mapping. Metaphorically, these clustering concepts represent “contact pins” for taxonomies. Other taxonomies, just like the one in Figure 4, could now be put side by side and the information could flow between them in a seamless manner. Virtual construction products could be easily matched to virtual manufacturing or financial products immediately. For example, consistent levels of “skill” could be defined for Actors in all three industries, hence, comparing the training strategies and development techniques among these industries. The codes of all three industries could also be compared as they relate to each process, product, or resource. In an e-business environment, it would be easier to verify that the requirements of such diverse codes have been met. If several operations research technique are used in one process that spans the three industries, an attempt could be made to select one technique and consistent parameters to analyze the process actions, build common project metaphor (or model) using consistent parameters, agree on final product attributes and subscribe to consistent metrics for performance measurement. Moreover, the use of lattice is also very helpful in merging several ontologies and in effective information retrieval. For example, let us assume that the first part of Figure 6a represent a taxonomy for Infrastructure Products. The second part includes a taxonomy for Infrastructure Finance (for simplicity, we assume that this taxonomy has one concept only: BOOT). Let us also assume that a system user is enquiring a set of corporate documents (D), each of these documents include a set of phrases (P) that include a set of concepts (C). Let us also assume that the user is querying for the concept of Bridge BOOT projects in these documents. This con cept does not have a match in first or second taxonomy. Let us also assume that Table 1 shows the phrases found in each document with the concepts related to Bridge BOOT. FCA algorithms could help link these two taxonomies (given that they are represented as lattice). Figure 6b shows the resulting lattice of the two taxonomies. Notice that the resulting lattice in Figure 6b represent a biased product of lattice 1 and lattice 2 according

Supporting ontology management

581

to Table 2. With various versions of Table 2, we could produce, dynamically, a biased common lattice that combines two lattices according to some specifications.

Table 2. Two taxonomies. Document

Phrase

Taxonomy 1 concepts

Taxonomy 2 concepts

D1

P1

IP, BS, WS

D2

P12

IP,BS

D7

P10

IP, TS, WS

D7

P15

IP,WS

BOOT

D10

P8

IP

BOOT

It is also perceivable th at we can replace the word “Document” in Table 2 by “Company”, the word “Phrase” by “Process” and the word “Concept” by “Activity”. The resulting lattice in Figure 6b would show the combinations of activities in the four companies in a dynamic virtual project. The combination of FCA and genetic representation of concepts could facilitate real time knowledge discovery and management as follows (see Figure 7): • A lattice (a taxonomy) could be generated through basic modeling that is later amended through FCA (to include counterintuitive concepts). Each concept will have a unique name and ID. • Let us also assume that several of these taxonomies are created for various industries. For example, the construction industry, the financial industry and so forth. • In a collaborative environment, FCA could be used to create a dynamic combined taxonomy that establishes interoperability among all three industries. As such, concept A in taxonomy 1 (the construction taxonomy, for example) could be linked to Concept B in taxonomy 2 (the financial taxonomy, for example). Moreover, if through the comparison of the genes, we discover that two concepts in the two taxonomies are similar (even though they have different names and ID’s) then we can create a instance human-independent mapping between the two taxonomies. For example, the construction industry view of products is focused on the physical products (buildings and highways, for example). On the other hand, the financial industry list of products is almost all logical products (a loan or a fund, for example). The gene comparison could reconcile these two cultures as it will define both as Product. This, perceivably, will allow three organizations to collaborate through dynamically matching their ontologies/processes on line. This means that each could keep their own semantic representation, yet they can collaborate perfectly due to the dynamically created combined concept lattice (through lattice algebra).

eWork and eBusisness in architecture, engineering and construction

582

Figure 7. Dynamic process matching in collaborative environments. ACKNOWLEDGEMENTS The research work was supported mainly through the “Interoperable Infrastructure Management Systems” Project, which was funded by the Natural Sciences and Engineering Research Council, Canada. Additional funding was also provided by the Centre for Information Systems in Infrastructure and Construction, University of Toronto. Several graduate and undergraduate students from the University as well Canadian industry experts participated in the implementation and validation of some of the research thrusts. REFERENCES Freitas, A. (2002). “Data mining and knowledge discovery with evolutionary algorithms.” Springer. Fisher, D. and Langley, P. (1985). “Approaches to Conceptual Clustering.” Proc. 9th Int. Joint Conf. on AI, Los Angeles, CA. Fisher, D. (1987). “Improving Inference Through Conceptual Clustering.” Proc. AAAI Conf., Seattle, WA. Hull, R. and King, R. (1987). “Semantic Database Modeling: Survey, Applications, and Research Issues.” ACMComput. Surv., 19(3).

Supporting ontology management

583

Michalski, R.S. and Stepp, R. (1983). “Automated Construction of Classifications: Conceptual Clustering Versus Numerical Taxonomy.” IEEE Trans. Pattern Analysis and Machine Intelligence, 5. Haav, H-M. (2003). “Learning Ontologies for Domain-specific Information Retrieval.” In Abramowicz (Ed), Knowledge-Based Information Retrieval and Filtering from the Web, Kluwer Academic Publishers. Steimann, F. (2000). On the Representation of Roles in Object-Oriented and Conceptual Modelling. Data and Knowledge Engineering, ACM, Vol 35 (1).

eWork and eBusiness

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

An assessment methodology for eBusiness and eCommerce in the AEC sector A.Grilo Associate Professor Instituto Superior de Engenharia de Lisboa P.Maló & R.Jardim-Gonçalves Assistant Professors at Faculdade Ciências e Tecnologia da Universidade Nova de Lisboa, Senior Resercheres in UNINOVA ABSTRACT: Recent studies have illustrated that the AEC sector has embraced e-commerce and e-business. Indeed, case studies demonstrate that the use of electronic collaborative and commerce platforms by the different players in the AEC sector can be as sophisticated as the best practices found in Automotive, Aeronautics or Retailing sectors. However, the same studies do also recognize that though the best practices are at the same level, they are much less frequently deployed. This paper presents a methodology based on business factors to assess the readiness and likeliness of the development of e-Business and e-Commerce between the disparate players in AEC projects.

1 INTRODUCTION The AEC sector has embraced e-commerce and e-business, as demonstrated by recent case studies that illustrate the use of electronic collaborative and commerce platforms by the different AEC players. These applications can be as sophisticated as the best practices found in Automotive, Aeronautics or Retailing sectors, though they are much less frequently deployed. In order to create the enabling conditions for the deployment of the electronic collaborative and commerce platforms it is fundamental to understand the variables that may influence its development, and how they determine the configuration of the e-platform. E-COMMERCE AND E-BUSINESS FUNCTIONS 2.1 Informational The initial use of the Internet technology for business purposes had mainly an informational function. Web pages describing companies’ services and products were, and still are, the simplest and most common usage of an e-platform. The informational function has evolved and currently, more than just simple Web pages with descriptions, some companies make available databases with sophisticated data about products,

Ework and ebusiness in architecture, engineering and construction

586

services and the interaction (through business intelligence tools), including 3D CAD components to be embedded in 3D CAD applications. Architects, builders’ merchants, contractors, consultants, suppliers, etc, widely use this function. 2.2 Transactional The electronic exchange of commercial data relates to the transaction life-cycle, from the request for quotation, order, etc. until invoice. Before the availability of the Internet as a communication network, companies used X.25 based technology for Virtual Areas Networks (VAN) to exchange Electronic Data Interchange (EDI) messages. There was scarce use of this transactional ftmction in the AEC sector ten years ago (see Baldwin et al, 1995 or Akintoye and McKellar, 1997), and its use was mainly restricted between builders’ merchants and their suppliers. This reality has changed in the last years. The emergence of the virtual marketplaces has dramatically changed the use of transactional function, with contractors, suppliers, builder merchants, consultants and clients exchanging request for quotations, orders, invoice, etc. through these platforms (Flood et al, 2002; PRODAEC, 2004). Often denominated as e-procurement, this functions is rarely exploited at its full. The reason lies in the lack of integration of the companies’ internal ERP systems with the marketplaces. Thus, most of the companies type the transactional information in a Web browser and receive data in a file that print before re-introducing data manually in their ERP system. 2.3 Collaboration The oldest and simplest way of the collaboration function is the exchange of files through e-mail. This is a pervasive way of companies using an e-platform for collaboration. However, very sophisticated tools have emerged in the last years. Initially, the deployment of private Extranets allowed disparate parties in construction projects to share information by uploading and downloading files in a central server. More recently several commercial collaborative tools have appeared in the market, with very complex and complete functions like on-line CAD red-lining and markup, forums, logs registration, workflow, etc. Examples are Buzzsaw (see Autodesk, 2004) of Autodesk and ProjectNet of Citadon (see Citadon, 2004). These sophisticated tools are mainly used in large-scale construction projects (see PRODAEC, 2004). 2.4 Configuration of the e-platform These three functions can occur simultaneously between two companies. The degree of sophistication can vary, from the simple usage of e-mail usage or having a Web page with basic information, to intense marketplace transaction and use of a complex collaborative tool with workflow and on-line CAD redlining. The technology is availabe, it is reasonably inex pensive, de jure and de facto exist to facilitate exchange of files and data. Security issues, once a concern for users, are hardly an excuse as most professionals age below 40 years use home-banking, a much more data sensitive world. Case studies have demonstrated that the AEC sector can deploy and use

An assessment methodology for eBusiness and eCommerce in the AEC sector

587

sophisticated configuration of e-platforms (PRODAEC 2004). The main issue is, Why is it not more widely used?—The answer is on the business side of the problem. BUSINESS FACTORS 3 3.1 Companies’ Individual Features A determinant factor for the likeliness and readiness of a company to engage in any IT development (Venkatraman, 1991) and particularly in e-business or e-commerce is its internal features, namely: • Business Strategy, Organizational Infrastructure and Processes. Companies prone to innovation in all sides of the business, aligned with a strong, centralized organization and leadership are positive factors. Streamlined processes are fundamental to be able to take advantage of collaborative and transaction functions. Teams IT proficient are also crucial, particularly for collaborative functions. • IT Strategy, Infrastructure and Resources. Companies with low level of IT automation and integration between application, with significant legacy systems, and non-Web based applications may experience major difficulties. Availability of IT resources, either internal or contract out is important, though cost of implementing these tools are significantly low nowadays. 3.2 Relationship The relationship between firms is very important for the deployment of an e-platform between two firms. There are two main dimensions that should be analyzed (Hakansson and Snehota, 1995): • Exchange Episodes. The more intense, frequent and regular are the exchanges of information between firms the more likely they to use e-platforms, and the increased sophistication of the system. This is reinforced when also occurs strong product/service and financial exchanges. If the transactional type of information is the more intensely exchanged it is likely that an e-platform with more transactional function be developed. Conversely, if the nature of the relationship is mainly regarding the exchange of information needing collaborative interaction then collaborative type of e-platforms are likely to emerge. • Atmosphere. It is not only what is exchanged but also how it is that is important. Thus, close relationships, with strong bonds, institutionalized co-operation, and mutual expectations—that develop and evolve over time—is a very important driver for deployment of sophisticated e-platforms. The power dependency may also contribute, though if not on a conflict basis.

Ework and ebusiness in architecture, engineering and construction

588

3.3 Production Network Firms are not isolated in the market, firms tend to organize in production networks (Harrison, 1994), being the AEC sector networks very dynamic. The characteristics of the network influence in two major ways: • Governance Structure. Networks with a strong core, where the leading firms are prone to innovation and e-business technology is a very important driver. Examples can be found on construction projects with innovation and leadership commitment clients, or when project/construction managers with e-business focus are contracted. Ideally, the augmented core of the network, composed by Client, leading Architect/Designer and Main Contractor should have a good degree of e-business readiness and commitment. • Input-Output Structure. A small number of production units and firms in a network, and these with reasonably homogeneous size, IT capabilities, and streamlined processes are clear facilitator for e-business deployment, particularly for collaboration fimction. However, often e-platforms require a critical mass of users for the return of investments. 3.4 Interplay of Business Factors The deployment of e-platforms and their degree of sophistication is influenced not by just one business factor but from the interplay of factors. The larger the alignment between current conditions of firms’ internal features, relationships and the characteristics of the production network, with what was identified as the e-business/e-commerce facilitating conditions of the factors, the more likely the deployment of e-platforms and the more sophisticated the systems can aim to be. 4 E-BUSINESS/E-COMMERCE ASSESSMENT METHODOLOGY The proposed assessment methodology is based on the previous described factors and grounded on empirical work by Grilo (1998). The assessment methodology consists on a Gap Analysis regarding the previously defined factors and the situation of potential deployment of e-platform. To visualize this Gap Analysis, it is used a radar graphic, as depict on the Fig. 1. The widest the cover of the factors the higher the degree of readiness for deployment of e-platforms but also more likely sophisticated systems can emerge. The function typology can be analyzed through the Exchange Episodes, particularly the informational and product exchanges. If two companies exchange essentially technical and managerial information (Atkin, 1995) then it is likely that applications with collaborative functions are developed. Conversely, if companies exchange mainly commercial information, than the transactional function occurs.

An assessment methodology for eBusiness and eCommerce in the AEC sector

589

Figure 1. Example of the assessment graphic.

5 ECONSTROIAND MOTA-ENGIL In order to illustrate the analytical function of the methodology, a case study is described, based on PRODAEC research. The econstroi.com is a construction-oriented initiative that targets the entire sector in Portugal. It represents an ambitious attempt to integrate a value chain that potentially involves 80.000 companies. The econstroi.com project was launched in 2000. It started considering the use of the Internet to improve the business processes as well as some functions that exist in the fragmented construction industry where the buying process is particularly detailed and demanding in terms of information flow. Initially, econstroi.com .com .com provided only informational functions and by October 2001, it has started to operate in its core business: an instrument to support the electronic commerce for the construction sector. Nowadays, econstroi.com .com .com has combined the three functions: informational, transactional (the most used), and also some collaboration features. • Ask for information and share documents or project models among the participants in the same project; • Request and answer to proposals; • Compare budgets and choose among them the best proposal and carry out the respective orders and selection process;

Ework and ebusiness in architecture, engineering and construction

590

• Coordinate the logistic process; • Contract financing services and perform financial transactions. Construction companies can join the econstroi.com market for free. However, they are required to go through a registration process, which includes authentication and prequalification procedures. All goods, services and information are provided in a safe and confidential environment based on encrypted and closed communication channels. The econstroi.com has introduced innovations on the critical processes of the construction value chain, namely e-procurement and e-project management. Regarding the e-procurement, the econstroi.com way of working match buyers and sellers, comparing who is looking for the best offer/price and quality conditions against who is selling their products and services. Econstroi.com .com acts as a facilitator for

Figure 2. EConstroi.com this matching to happen in the same way that it takes place in the physical market. The e-project management manages all information (technical, financing contractual specifications) that is necessary to perform construction projects. This is a process that demands the involvement of a large number of entities (promoters, regulators, contractors, project managers, suppliers, etc) and demands a very intense and continuous exchange of documents mainly CAD drawings. Mota-Engil is a Portuguese general contractor, and is the company with the highest number of transactions in the portal, and with 90% of procurement through econstroi.com. Despite using the e-platform mainly for transacting exchanges, uses it to

An assessment methodology for eBusiness and eCommerce in the AEC sector

591

its full extent. The degree of sophistication in terms of the transaction function is very high, having Mota-Engil integrated their internal ERP SAP application with the portal, in order to reduce re-typing, or manual upload and download of files. It does not cover digital invoicing, since legally in Portugal it is not accepted. • Business Strategy, Organizational Infrastructure and Processes. Company has very streamlined processes, with centralized supporting departments. It has been in the forefront of innovation regarding construction methods, management, IT, quality assurance and recently in environment and health and safety. • IT Strategy, Infrastructure and Resources. MotaEngil has most of the documents in digital format, with workflow implemented. All sites are connected to central ERP system. High degree of automatized processes. • Exchange Episodes. Mota-Engil exchanges mainly request for quotations, tenders and supporting

Figure 3. Assessment of econstroi.com/Mota-Engil readiness of development of an e-platform. technical documents with their suppliers. Despite the use of the portal has opened the market for the contractor, in generic terms, previous relationships with higher number of transactions are still the most frequent users of the system. • Atmosphere. Despite econstroi.com enables market to work, with new suppliers coming in, most of Mota-Engil suppliers adhering to the e-platform, worked previously for many years with the contractor, with strong institutional and personal bonds. The market conditions (price, quality, delivery) are crucial, but still, new comers have to pass a confidence threshold in the procurement process for buys above certain budget. • Governance Structure. Clearly Mota-Engil is a core leader in the network of its suppliers. Traditional suppliers were warned that they have to trade through econstroi.com—despite being given a period to adapt themselves, or are out of

Ework and ebusiness in architecture, engineering and construction

592

business with the contractor. Most of suppliers are complying with the request, showing the leadership governance capability of Mota-Engil. Curiously, the least adherent are the companies that are on the loose end of the network ring, some of them well known and large companies but that do not dependent much of Mota-Engil for their overall business. • Input-Output Structure. The number of companies on Mota-Engil suppliers’ network is high, and their characteristics very heterogeneous. This has clearly been a problem due the need to convince them all to adhere to the system, training, etc. Particularly for small supplier, to whom connecting to the Internet is far from trifle. Figure 3 presents the assessment made. It is easily concluded that in this case Mota-Engil had a reasonably high degree of readiness for the deployment of an e-platform. The assessment graphic does also show that the Input-Output structure of the network is the main hindrance to developments and sophistication of the system. Indeed, it was this area of concern that has deserved the biggest efforts by Mota-Engil managers in the last year for the full scale implementation of the digital procurement process. 6 CONCLUSIONS This paper focused on describing a methodology in order to systematize the analysis of development of e-business/e-commerce platforms and their degree of sophistication. It was argued that technology in itself is hardly an important factor as business factors are: Individual Features of companies, like their business strategy and organisational infrastructure and processes, IT strategy, infrastructure and resources; the characteristics of the Relationship between companies, addressing issues like the type of informational and product exchanges as wel.l as the atmosphere between the parties; and the Production Network where companies are embedded, with variables like their governance structure and input-output structure. A case study was described, and it is possible to conclude that based on this methodology, managers can act accordingly in order to create the enabling conditions for the deployment of the electronic collaborative and commerce platforms. REFERENCES Akintoye, A. and McKellar, T. (1997). Electronic Data Interchange in the UK construction Industry. RICS Research Paper Series, 2:4, London Atkin, B. (1995). Information management of construction projects. In Integrated construction information. Ed. P. Brandon and M.Betts, Chapman & Hall, London Autodesk (2004), http://usa.autodesk.com/ Baldwin, A., Thorpe, A. and Carter, C. (1995). An internal survey report on the Construction Industry Trade Electronically Group—CITE, Loughborough University of Technology, Loughborough Citadon (2004), http://www.citadon.com/ Flood, I. Issa, R and Caglasin, G. (2002). Assessment of ebusiness implementation in US Construction Industry. eWork and eBusiness in AEC; Turk & Scherer (eds), Swets and Zeitlinger

An assessment methodology for eBusiness and eCommerce in the AEC sector

593

Grilo, A. (1998). The development of electronic trading between construction firms. Unpublished PhD Thesis, University of Salford Hakansson, H. and Snehota, I. (1995). Developing relationships in business networks. Ed. H.Hakansson and I. Snethota; Routledge, London Harrison, B. (1994). Lean and mean: the changing land-scape of corporate power in the age of flexibility. Basic Books; NY PRODAEC (2004), http://www.prodaec.net/, as in June 2004 Venkatraman, N. (1991). IT-induced business reconfiguration. In The Corporation of the 1990s: information technology and organizational transformation. Eds M.Scott Morton

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

The digital dormer—applying for building permits online J.P.van Leeuwen & A.J.Jessurun Eindhoven University of Technology, Department of Architecture, Building, and Planning E.de Wit Municipality of Rotterdam, Department for Urban Planning, Housing, and Traffic ABSTRACT: This paper discusses the objectives, functionality, and implementation of a tool that supports the online ap plication for building permits for dormers. Using the simple interaction of this tool, civilians can design a dormer on their house and receive feedback on the necessity to request a building permit for the dormer. The tool also provides feedback on whether or not the design of the dormer passes the criteria that are posed by national and local authorities regarding the aesthetical aspects of dormers. The paper concludes with a discussion of future developments of this project as well as its impact for the innovation of civil administration.

1 INTRODUCTION The municipality of Rotterdam yearly receives around 2,500 applications for building permits. Approximately 1,000 of these concern larger construction projects of new buildings, such as office buildings, housing prqjects, and single private houses. The other 1,500 permits are requested for smaller projects, mostly for extensions and modifications to houses. Of these, around 300 projects involve the extension of houses by placement of dormers. The construction-costs of these dormers vary between € 2, 500 and € 35, 000. The licensing procedure for dormers is relatively straight forward, compared to that of most other building permits. The variety and complexity of this kind of constructions is limited and the regulations for approval are strictly defined by most municipalities. This offers an opportunity for automation of the process, from which we can learn to later address other, more complex, projects as well. An example of how governmental services can be made available online, mainly by providing structured information to civilians and ofFering tools for the support of the application process, is found in the UK (Planningportal, 2004). The objective of the project described in this paper is to ease both processes of applying for permits and granting permits for the construction of dormers. This is achieved by the development of a web-based tool, called the Digital Dormer, that allows civilians to ‘design’ the dormer on their house and to submit the information that is required to perform automatic checking with national as well as local regulations.

The digital dormer-applying for building permits online

595

Ultimately, the tool also generates all documents (forms and technical drawings) that are necessary to submit an online building permit application for the dormer. Research on building codes checking already has some history. Acknowledging that the main problem is not just in formalising the building codes, but in unambiguously describing the building information, much effort has been targeted at standardisation of building models, e.g. (Vanier, 1995). More recently, other approaches have been developed that take advantage of more flexible technologies (Woodbury et al., 2000; Tang and Xiang, 2001). While dormers as the targeted kind of construction work are relatively small, the technological challenges in developing the software for this tool are significant and the potential impact on further automation support of public procedures is considerable. The main technological challenges for developing the required functionality in this project were: • to offer sufficiently simple ‘graphical design’ tools for use by lay persons, with a good balance between the realism of the representation and the level of user-interaction required; • to provide an attractive and informative feedback system that acquires all information from the user that is necessary to evaluate the design using criteria from zoning plans as well as from the local policy on building aesthetics; • to perform the checking of both geometrical and non-geometrical criteria regarding the position, size, and other characteristics of dormers with respect to the specific context of the house and its location. Additionally, important requirements for the application were: • to minimize the requirements of client-side software to what can be expected at people’s homes: just a web browser; • to have a flexible software architecture to be able to vary the context in which the software will be applied, regarding the type of houses and dormers and the contents of the criteria. The paper describes how these challenges were countered in the developed application. It describes the functionality of the system which provides: parameterised stereotypes of houses and dormers; a graphical engine for dynamically rendering the visual feedback; code checking functionality; and a web application that provides interfaces for the users’ activities. The paper then discusses the further development of the system and concludes with a discussion of the potential impacts of this project. First, however, we will briefly discuss the regulations concerning building permits for dormers in the Netherlands. 2 BUILDING PERMITS FOR DORMERS The regulations concerning building permits for dormers in the Netherlands are established on both national and municipal level. At the national level, there are regulations by the Dutch Ministry of Housing (VROM) that state when a dormer can be

Ework and ebusiness in architecture, engineering and construction

596

build without applying for a building permit. This largely depends on a number of geometrical criteria for location and measurements of the dormer, and on the status of the existing building as a registered monument. If the particular situation does not fulfil the criteria of these regulations, a building permit must be requested from the local municipality. The local municipality will evaluate the building permit application on three aspects: 1. Zoning plan: does the spatial profile of the area in which the dwelling is situated allow the extension of the built space with this dormer; 2. Construction law: these are the building codes related to structural safety and, e.g., energy performance. Which of these codes apply depends on the type of permit that is necessary. Municipalities generally distinguish light permits (structural safety only) from regular permits, where the latter are required for larger construction plans; 3. Aesthetical aspects: The municipal aesthetics committee assesses applications on aesthetical aspects. Their working methods are generally laid out in a local aesthetics policy note. As of 1 July 2004, municipalities are by law obliged to provide this policy note. While these notes are the responsibility of municipalities, the Dutch Ministry of Housing aims to have these municipal notes as unambiguous as possible, in order to ensure equality of rights (VROM, 2004). The aesthetics policy note for Rotterdam is published in (Gemeente Rotterdam, 2003). The project described in this paper addresses the automatic checking of the national regulations and of aspects 1 and 3 of the local regulations above. Building codes regarding technical issues are not automatically checked at this stage. 2.1 Procedure of evaluation The procedure of evaluation of the building permit application is driven by the aforementioned criteria. The outcome of the evaluation of the criteria can be summarised in the following schema, which states the consequences of satisfying and not satisfying the criteria at the national and municipal level. It should be noted that the evaluation of the municipal criteria merely functions as an indication for the eventual outcome of the committee’s assessment of the application. If these criteria are not satisfied, the normal procedure for building permits is followed. Satisfied

Not satisfied

National criteria

No building permit required.

Building permit required.

Municipal criteria

Building permit likely to be granted.

Building Permit not sure.

2.2 Criteria for dormers The criteria for the building permits for dormers mainly comprise the following types: • Geometrical criteria. These relate to the dimensions of the dormer and its location on the roof. An example of these criteria is: ‘The distance from the side of the dormer to the edge of the roof is at least 0.5 m; if the house is next to a public green space or road, this distance is at least 2 m.’

The digital dormer-applying for building permits online

597

• Design criteria: These relate to the shape of the dormer and, e.g., the design of its front. • Material usage. • Colour usage.

3 FUNCTIONALITY OF THE TOOL The description of the functionality of the Digital Dormer website in this section is related to the general flow of the dormer design process (see Figure 2) that is offered to the user in six major steps. These steps are represented in the site’s menu and the background process for these steps is integrated with the two main server tasks for code checking and visualisation of the house and dormer.

Figure 1. User interface for dimensioning the house.

Ework and ebusiness in architecture, engineering and construction

598

Figure 2. General flow of the dormer design process: six steps of user input integrated with two main server tasks. 3.1 Selection of criteria by postal code The user enters the postal code and house number of his address. This information is used to verify the address and to select which local aesthetics criteria are applicable. Additional information regarding the nature of dwelling is asked, in order to perform the first checks with the national regulations on building permits for dormers. In case the building is registered as a monument, a building permit must always be applied for.

The digital dormer-applying for building permits online

599

3.2 Selection of stereotype house The design process in the application is based on stereotypes of houses and dormers, where the house stereotypes in fact concern roof types. There have been two reasons for this decision. One is that reduction of the design space, and thus simplification of the otherwise complex process, can be achieved this way. A justification for this is that 80% of the house stock can be covered with around 7 stereotypes. A second reason is that the criteria for dormers are based on a number of variant roof types. It thus appeared logical to use these roof types as point of departure. The stereotypes are represented by parameterised geometric models. After the user has selected his type of house, he can proceed to input the various dimensions for it. 3.3 Dimensioning the house The number of parameters of the geometry of the house is reduced to the minimum that is required to perform the code checking. In the case of the most simple roof type, these parameters are: 1. Width and length of the house; 2. Height to the ridge and height to the base of the roof. Figure 1 shows the user interface for entering these parameters. The image of the house is dynamically updated when changes to the dimensions are submitted. In addition to the geometric parameters, there are two parameters that specify the usage of the neighbouring ground to the house. For either side, the user can indicate whether or not there is a connecting house or a green space or public road. These parameters also influence the applicability of the criteria, e.g. the minimum distance between the side of the dormer and the edge of the roof. 3.4 Selection, location, and dimensioning of the dormer Similarly, the type of dormer and the values for its geometrical parameter must be specified. In addition, the user must indicate on which surface of the roof the dormer will be located.

Ework and ebusiness in architecture, engineering and construction

600

Figure 3. Dimensioning and positioning the dormer. At this point, a number of criteria are again checked. At the national level it is established that dormers located at the front side of the house cannot be built without a permit. The dimensions of the dormer and, in particular, the distances from the boundary of the dormer to the edges of the roof are bound by criteria at national and municipal level. The code checking is performed at the background, on the basis of the value of parameters, but feedback to the user is presented directly in the interface. For details of the code checking, see section 3.6 and section 4.4. 3.5 Visualisation of house and dormer As shown in Figure 1 and 3, the actual state of the design is shown in a graphical representation of the parametric geometry. These are still image renderings of the 3D model, which can be easily incorporated into the application’s website, without any requirements for client-side applications. In the configuration of the system, various camera viewpoints can be configured. An additional feature of the system is that the user can upload a digital photograph of the front elevation of the house, which will then be used as a texture on the 3D model as shown in Figure 3. The portion of the photograph that contains the elevation is cut out by the user through a very simple point and click method, shown in Figure 4. The red corners are positioned according to the nearest mouse-clicks on the image.

The digital dormer-applying for building permits online

601

3.6 Code checking The application performs three types of code checking procedures. These procedures take place at

Figure 4. Cutting out the elevation from the photograph. server-side, invisible to the user, but feedback to the user is given at each relevant stage in the process. 1. Basic test. This is a geometrical check of the user’s input. It checks the logical correctness of sizes. Examples are: all sizes>0, height to roof-base
Ework and ebusiness in architecture, engineering and construction

602

checking, by way of a traffic light in the upper right corner. The table shows the meaning of the various lights. 4 IMPLEMENTATION ISSUES 4.1 Modules of the system The system was designed as two communicating server applications. 1. The Dormer Render Server (DRS) is an internal process that contains the procedures regarding the parameterised geometry, produces the graphics of the requested geometry, and performs the code checking.

Table 1. Three types of test with interdependencies and visual feedback. When performed?

If satisfied, then

Basic test

Always

Input is logically correct

(blinking orange light) Logical error in user input

VROM test

If basic test satisfied

Building permit is not required

Building permit is required

Aesthetics committee is likely to agree

Approval of aesthetics committee is not sure, at this stage the normal procedure for building permit application is followed.

Aesthetics If VROM test not test satisfied (a permit is required)

If not satisfied, then

Figure 5. System Architecture.

The digital dormer-applying for building permits online

603

2. The Dormer Web Application (DWA) is a web application that generates the necessary web pages and processes the related requests for the interaction with the user. These two applications communicate internally with XML formatted data and using the HTTP protocol in order to share the requested and generated data (see Figure 5). 4.2 Technical approach The DRS application is a server application that accepts HTTP requests to perform two tasks: 1. Requests to render graphical images of the house and dormer geometry; 2. Requests to perform the checking of the three kinds of criteria. The implementation of this application involves two modules. The Open Scene Graph rendering library is used to generate the images. A Perl scripting engine is used to generate the geometry for the OSG calls, and to perform the code checking. The DWA application is built upon an Apache web server and utlises PHP script to dynamically generate and handle the user interface. The development of the system was mainly done using the following software tools and technologies. • Microsoft’s Windows 2000 Server operating system; • Apache web server with PHP programming environment; • XML data format for exchange between the two applications; • Autodesk’s 3D Studio Max for the generation of the basis geometries; • Open Scene Graph for the production of the graphical representations; • Perl script environment for the parameterisation of the geometries; • Microsoft’s Visual Studio 2003 for development of the DRS application. While the objective of the project is to utilise only open source software and open standards, commercial software was utilised only for the development of the applications. The resulting applications can operate on an open source basis. 4.3 Parametric geometry The parametric geometry for the house and dormer types is generated from a geometric basis created in 3D Studio Max. Including its textures and light sources, this geometry can be exported using a plug-in for the production of Open Scene Graph files. This plugin was enhanced for the purpose of this project to export a Perl script that contains a version of the geometry that includes labelled vertices. These vertex labels can be added to the geometry in 3D Studio Max by the developer, prior to performing the export. After this Perl script with labelled geometry is produced, it can be manually modified by the developer into a parameterised version, based on the parameters defined for the user interaction. Besides the Perl script, a configuration file is exported that contains additional data concerning the configuration of the cameras.

Ework and ebusiness in architecture, engineering and construction

604

4.4 Digital format of the criteria The criteria from the Basic test, the VROM test, and the Aesthetics test were digitally represented in a dedicated XML format. In this format, references are made to the parameters used for the description of the house and dormer types. The criteria are specified within the XML format in the form of Perl expressions that can directly be evaluated by the Perl engine which is a module of the DRS application. The tests are performed by the DRS application. This application contains an engine that can perform any type of test that is expressed in the defined XML format. The distinction between the three types of tests is not made within this engine. In fact, only the DWA application that sends the requests for testing to the DRS test engine presents the distinction between the three types of test in the textual and visual feedback to the user. 5 FURTHER DEVELOPMENTS The procedure of applying for a building permit is not completely implemented with the current state of the project. Although much information regarding the dormer design is already acquired from the user at this point, some additional information will be necessary to generate the technical drawings required for the building permit application. • Section drawing. The process of drawing a section of the dorme and roof will be implemented by means of standard details for the construction of dormers. A limited number of such standard details will be produced in parameterised form, representing the types of dormer constructions that are suitable for the various roof construction types. Probably another differentiation will be necessary for ranges of roof slopes. Additional user input that will be required includes the type of roof construction, the height of the floor level, and a floor plan. • Floorplan. A drawing of the modified floor plan will be super-imposed on a scanned image of the existing floor plan. Similar to the way the photograph of the elevation is applied as texture to the 3D model, the scanned floor plan can be used to generate the new floor plan from the available 3D geometry. Additional information regarding spatial layout and wall thickness can be obtained from the user either numerically or by graphical interaction with the uploaded scan. • Administrative forms. With simple extensions to the web interface, the information concerning the applicant can be acquired and entered into automatically generated forms that will be used for online application at the municipality. In this context, collaboration in this project will be sought with another national initiative for the implementation of a central server for building permit applications. Apart from the above-mentioned developments, an inventory of necessary improvements is made and reported for the subsequent stages of this project. Many of these regard the

The digital dormer-applying for building permits online

605

user interface and the enhancement of the feedback of test results. A detailed discussion of these issues is not relevant within the scope of this paper. 6 IMPACT AND UTILISATION The potential impact and utilisation of the results of this project are manifold. Firstly, the type of technology developed and applied in this project enables civilians to be well informed about the possibilities of their plans without the need to go through lengthy procedures before taking any decisions. Secondly, the online application for building permits is strongly supported by the tool: information is gathered, checked, and made available to municipalities in a format that is easy to handle. This will reduce the administrative workload related to these relatively low-cost construction works. Thirdly, the organisational approach that underlies this project makes it possible for municipalities to promote best practices and preferred designs and constructions with respect to dormers. A commercial spin-off of this development could also be achieved by relating the site to a digital market-place for construction companies that specialise in this type of construction works. However, legal issues need to be studied with respect to such direct relationships with commerce. Finally, while this project deals with permits to build dormers, it is part of a set of initiatives that aims to provide digital support for applying and granting building permits in general. As such, the Digital Dormer project functions as a pilot project in the context of the afore-mentioned initiative for a central server for building permits that centralises the communication between civilians and their municipalities regarding building activities. While these developments are still in preliminary phase, the Dutch Ministry of Spatial Planning, Housing and the Environment (VROM) has already expressed strong interests in these projects. The Digital Dormer website will in the near future be made available to municipalities and civilians, probably under the management of a foundation. Municipalities will have access to tools that enable the specification of their local criteria. Civilians will have access to evaluate their plans and, with minimal costs, to apply for the permit if necessary. Extrapolation of the concepts developed in this project, with respect to other kinds of building permits or even other kinds of civil services, may seem obvious but must be considered with caution. Much of the success of this project relies on the ability to express building information in parametric form. Whether this success can also be achieved in other circumstances remains to be proven. Also, a broad social discussion should lead to an indication of the limits to automating design and design evaluation processes. Although the authors believe that the increased responsibility and active participation of civilians in the development and design of our built environment are strongly desirable, the value of expert knowledge and experience must not be trivialised. ACKNOWLEDGEMENTS

Ework and ebusiness in architecture, engineering and construction

606

The Digital Dormer project is initiated by the Municipalities of Rotterdam and Zoetermeer. Its first stage of development was financed by InAxis, a committee for innovation of civil administration from the Dutch Ministry of Internal Affairs. Project management and public relations were under care of the foundation SAV€. REFERENCES The web application of the Digital Dormer can be accessed temporarily (during 2004) at: http://www.ds.arch.tue.nl/research/projects/DigitalDormer Gemeente Rotterdam. 2003. Koepelnota Welstand Rotterdam, voorontwerp 2003. Municipality of Rotterdam. Planningportal. 2004. Portal website for the British town and country planning system: http://www.planningportal.gov.uk/ Vanier, D.J. (1995) Canada and computer representations of design standards and building codes, The Int. Journal of Construction IT 3(1), pp. 1–12 VROM. 2004. Website of the Dutch Ministry of Spatial Planning, Housing and the Environment (VROM) with information on Dutch laws for housing and building permits: http://www.vrom.nl/international (in English) http: //www.vrom.nl/woningwet (in Dutch) http://www.vrom.nl/bouwvergunningen_online (in Dutch) http://vrom.nl/bouwbesluit_online (in Dutch) Woodbury, R., Burrow, A., Drogenuller, R. and Datta, S. (2000) Code checking by representation comparison, Proceedings of CAADRIA2000, Singapore, pp. 235–244 Yang, Q.Z. and Li, Xiang (2001) Representation and Execution of Building Codes for Automated Code Checking, Proceedings of the Ninth International Conference on ComputerAided Architectural Design Futures [ISBN 0–7923–7023–6] Eindhoven, 8–11 July 2001, pp. 315–329

Information regarding the open source sofrware used in this project can be found here: OpenSceneGraph: http://openscenegraph.sourceforge.net/ Perl: http://www.perl.com/ ActivePerl: http://www.activestate.com/Products/ActivePerl/ Apache Webserver: http://www.apache.org/ PHP: http://www.php.net/

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

An inquiry into building product information acquisition and processing A.Mahdavi, G.Suter, S.Häusler & S.Kernstock Department of Building Physics, Vienna University of Technology ABSTRACT: Building product information provided by manufacturers and publishers should reflect the actual patterns of information acquisition and processing by those involved in the building delivery process. However, little factual data is available in that respect. This paper presents an empirical inquiry into product information acquisition and processing by architects and building owners in Austria. The results suggest that there are considerable differences between the two groups with respect to information needs, reuse of information, and information sources. Paperbased product information and personal conversations with sales representatives remain the preferred information sources for both architects and building owners. The present role of electronic media in product information processes appears rather small.

1 INTRODUCTION Several studies have been conducted to assess the use of information technology in construction. Most recently, Rivard et al. have investigated information technology use patterns in the Canadian construction industry through case studies and surveys (Rivard et al. 2004, Rivard et al. 2000). Similar studies exist for other countries (see, for example, Issa et al. 2003, Samuelson 2002). These studies generally share an emphasis on the use of information technology in various construction and business activities. In contrast, our focus in this paper is specifically on the current needs and habits (which may or may not be supported by electronic tools) of building practitioners with respect to acquisition and processing of building product information. In the context of this paper, the term building product primarily refers to manufactured components that are used to construct buildings. In the past decades, various research efforts aimed to improve the information flow between manufacturers and design professionals. Most of these projects developed solutions that would address the limitations of traditional paper-based media such as paper-based product catalogs. Work by Amor and Newnham (1999) and Jain and Augenbroe (2003) demonstrates the potential of tight integration of electronic product information into the work flow of architects and its impact on the product selection process. In Austria, Seiffarth (1989) initiated a project for an Austrian building product information system based on television display technology. A survey gathered user expectations from such a system. As the tools and processes in architectural firms have changed dramatically since then, a re-evaluation of those expectations is necessary to inform future research and development efforts. More recent case studies of

Ework and ebusiness in architecture, engineering and construction

608

manufacturers and architects by Jain & Augenbroe (1999) document decision and process patterns related to product information. Finne (2003) investigated the potential impact of electronic commerce on information intermediation services in the construction industry. With improved internet accessibility, many product information providers nowadays use the internet as an additional communication channel (see, for example, Heinze 2004). However, as research in economics and human interaction research suggests, this requires considerable and often costly adaptation of existing documentation to take full advantage of electronic media (see, for example, Katz and Byrne 2003, Hoque and Lohse 1999). So far, especially product information offerings on the internet appear to have been driven by technology rather than actual information and processing needs of user groups. Still, comparatively little factual data is available concerning the actual patterns of product information acquisition and processing by those involved in the building delivery process. This paper presents the results of an exploratory, local effort to address this knowledge gap. It reports on an empirical inquiry into the patterns of product information habits and needs of architects and building owners in Austria. Within the constraints of the study, which was funded by the Vienna Chamber of Commerce, these two groups were chosen mainly because they are usually deeply involved in product-related decisionmaking in construction projects. Respective data was collected using internet-based questionnaires as well as telephone-based and personal interviews. The paper entails a summary and discussion of the findings and highlights their implications for computational research and development efforts in the areas of building product selection support. 2 ARCHITECTS 2.1 Approach This portion of the paper presents the results from a study that investigated the building product information acquisition and processing habits of architects (Hausler 2003). It was carried out with an online questionnaire followed by on-site visits with participants who agreed to a personal interview. The decision for the former was made because many architectural offices in Austria nowadays have Internet access. The survey was limited to three provinces in Austria. Altogether 485 licensed architects were contacted by electronic mail. The mail included an explanation of the project objectives and a link to an internet page, which included instructions and the questionnaire itself. The response rate was 88 or 18% out of the 485 contacted architects, which is good for this type of survey (Table 1). The items in the online survey included questions about the participants’ background, product selection responsibilities, product information content/presentation, sources, and integration in work flow/processes. Whereas the questions in the online survey were asked in multiple-choice style, those in the personal interviews were more open-ended. The objective for the personal interviews was to gain a better understanding of survey trends and the habits of individual architects.

An inquiry into building product information acquisition and processing

609

2.2 Results Results from the online survey were processed electronically and, in some cases, aggregated and weighted

Table 1. Sample selection and response rate for electronic survey and personal interview. Number of architects Total number of architects (Vienna, Lower Austria, Burgenland)

1360

Licensed architects

880

Licensed architects with email address

540

Emails sent

485

Online survey participants

88

Interview participants

12

to facilitate analysis. This was done with those questions to which participants could respond by selecting more than one answer among alternative answers. An alternative answer would carry more weight if it were the only one that had been selected compared with the case where other alternative answers had been checked as well. Tables 2, 3, 4 and Figures 1–7 show selected results from the online survey. 2.3 Discussion According to the results from the survey and the interviews, architects view themselves as playing an active, leading role in the product search and selection process. Decisions regarding the use of a product in a building project tend to be made by design architects (46%) rather than owners (17%) or project leaders (15%, Figure 1). Although product information is relevant in all project phases, the selection of a product is often finalized only in design documentation and procurement stages (Figure 2).

Table 2. Type of employment of respondents (multiple selections allowed). Position

Number of respondents

Self-employed/partner

68

Employed

20

Free-lancer

9

Consortium member

3

Other

3

Ework and ebusiness in architecture, engineering and construction

610

Table 3. Size of respondents’ firms. Office size

Number of respondents

Percentage of respondents

0 employees

10

11.4

1–5 employees

48

54.5

5–15 employees

24

27.3

15–30 employees

3

3.4

30 employees and more

3

3.4

88

100.0

Total

Table 4. Age groups of survey respondents. Age group

Number of respondents

Percentage of respondents

Less than 30 years

13

14.8

30–40 years

22

25.0

40–50 years

28

31.8

50 years and older

25

28.4

Total

88

100.0

Figure 1. Who decides about the use of a product? The architects are most often interested in a product’s visual performance characteristics and pricing, followed by solutions for integration with other systems and technical information (Figure 3). Demand for information regarding product alternatives, contractors, and standard compliance is significantly lower. Although architects as well

An inquiry into building product information acquisition and processing

611

as manufacturers are increasingly aware of environmental issues, building ecology aspects do in general seem less relevant to the product information acquisition and selection process. A combination of two- and three-dimensional drawings, pictures, tables, and text are useful to explain product characteristics to an architect (Figure 4).

Figure 2. At what stage is a product’s use finalized?

Figure 3. How often do architects search certain aspects of product information?

Ework and ebusiness in architecture, engineering and construction

612

Figure 4. How important are product presentation styles for architects?

Figure 5. How is product information reused in the planning process? However, clear preferences seem to exist as far as reuse of product information into an architect’s workflow is concerned. This is where electronic product representations are useful. Product representations in the form of electronic two-dimensional drawings and text are frequently inserted into other documents. Whereas 76% of respondents indicated that they transfer manufacturer drawings electronically, 14% do so manually (Figure 5).

An inquiry into building product information acquisition and processing

613

Architects who agreed to be interviewed mentioned that electronic drawings are often adapted to a working document’s level of detail and representation style. Threedimensional drawings are significantly less important for reuse in an architect’s workflow. This finding is hardly surprising in light of abundant anecdotal evidence as well as feedback from the interviews suggesting that architects continue to rely on twodimensional drawings although most CAD tools provide fiill three-dimensional modeling capabilities. Paper-based catalogs (so-called “Architektenmappe”) appear to remain the most effective medium for manufacturers to promote and explain their products to architects. However, architects increasingly rely on a combination of information sources (Figure 6). For example, they contact sales representatives for specific technical questions because pricing and delivery information might vary among customers and locations. Somewhat surprisingly, the electronic media are still secondary in the product information acquisition process. Among electronic product information offerings, manufacturer sites are viewed as more effective for product search than online catalogs (Figure 7). This could be because the latter often resemble company directories rather than rich repositories of product information. Furthermore, even popular general-purpose search engines are viewed as slightly more effective for product search than online or CD catalogs. Since the latter often merely mirror company sites, their only benefit appears to be persistent access to certain product information for future reference. Although younger architects tend to rely more on the internet for product search than older ones, the overall product information acquisition and processing habits identified in this study appear to be largely independent of age, firm or area of specialization. Beyond index-based organization of paper-based catalogs and manufacturers’ internet sites, we have not found evidence that architects organize product information in a systematic way that would make the product search and selection process more effective across projects.

Figure 6. What are the architects’ product information sources?

Ework and ebusiness in architecture, engineering and construction

614

Figure 7. How effective are media for product information search for architevts? (Lines indicate standard deviations 3OWNERS 3.1 Approach There exists, to our knowledge, no previous study on the building product information acquisition and pro- cessing habits of the building owners in Austria. In the absence of a precedence, the scope of the inquiry and the identification of a proper sample had to be initiated ab ovo. It was decided to limit the study to Vienna. Moreover, only recently completed projects were considered. Identification of participants and the communication method turned out to be a formidable challenge. Given various constraints, the following process was followed: (i) Recent issues of a weekly publication (“Wiener Amtsblatt”) of the municipality of the city of Vienna were studied. This publication includes, amongst many other kinds of information, a list with the announcements of permission requests for construction projects. The list entails for each project a title, the location of the construction site, as well as the name and postal address of the owner. In some cases the type of the project is mentioned, whereby the following high-level categories can be discerned: (a)

An inquiry into building product information acquisition and processing

615

industry, (b) office, (c) residential (single houses, apartments, and adaptations), and (d) technical upgrades (mainly elevator installations). (ii) We limited our search to requests published early 2002 and considered only those with an identifiable building prqject category. This resulted in a total of 423 projects. (iii) Using this list and publicly available electronic information directories, the telephone numbers of 73 building owners could be identified. (iv) An attempt was made to contact the building owners via telephone. 35 could not be reached and 6 declined to participate. The remaining 32 building owners participated in the study. Table 5 provides a comparison of the distribution of different project categories in the initial project the sample of sample versus the participants in the study.

Table 5. Distribution of building project categories in the initial project sample versus participants (in %). Category

Industry

Initially selected projects Participants

Office

Residential

Technical

9

3

76

12

13

9

72

6

Table 6. Participants’ age for each project category (in %). Ageof participant

Industry

Office

Residential

Technical

Over 40

75

68

48

100

Under 40

25

32

52

0

Table 7. Participants’ experience for each project category (in %). Number of previous prqjects

Industry

Office

Residential

Technical

1

25

0

70

50

2 or more

75

100

30

50

Table 8. Participants’ occupation for each project category (in %). Occupation

Industry

Office

Residential

Technical

Office workers

100

100

52

–

Trade/industry

25

32

13

–

–

–

35

100

Non-active

Ework and ebusiness in architecture, engineering and construction

616

(v) Telephone interviews were conducted based on a questionnaire, which included three main sections: (1) general information about the background of the participants (age, profession, prior experience, etc.); (2) areas of interest in product information search; (3) types of building product information sources. (vi) Upon completion and analysis of the telephone-based interviews, additional in-depth personal interviews were conducted with 5 building owners. 3.2 Results Tables 6 to 8 and Figures 8 to 10 entail selected results from the telephone interviews. 3.3 Discussion Compared with the architects’ survey, sample size (88 vs 32 respondents) as well as the type and breadth of data obtained from owners are less amenable to detailed analysis. Nevertheless, some general observations can be made. Other than in the residential category, the majority of building owners are in the “older than forty” age category. Other than in the technical category, owners in industry/office project category are more experienced with building projects. Note that the interviewees in these categories are often technically educated professionals representing building owner groups and organizations.

Figure 8. What product information media do building owners prefer the most?

An inquiry into building product information acquisition and processing

Figure 9. What product information media are least desirable to building owners?

Figure 10. Information on what types of products is most frequently searched by building owners?

617

Ework and ebusiness in architecture, engineering and construction

618

As far as the preferred building product information sources are concerned, personal conversation with product representatives represents undoubtedly the most important source of information. The relative large number of those who do not express any clear preference means that many building owners use multiple sources and compare the information content they offer. Prevalent building product brochures constitute also a relatively popular product information resource for the building owners. However, brochures typically represent the starting point for information acquisition, which subsequently leads to the collection of more detailed and complete information via other resources. Electronic media (Internet and CD-Roms) find apparently the least level of acceptance amongst building owners. Generally, most building owners are interested in information on all kinds of products. The somewhat higher frequency of expressed interest in information on floor systems is probably due to the fact that they can be implemented in smaller residential projects by building owners themselves. The results of the personal interviews with the building owners may be summarized as follows. As with the architects, two kinds of search habit may be found by building owners. The first is project-dependent and is typically triggered by mailed brochures on building products. Apparently such material, if prepared professionally, can catch the attention of the addressees and thus be remembered, once a concrete building project is at hand. The project-centric search is tied with a concrete project and follows the overall scheme of the building delivery process. Personal conversations with product representatives or other knowledgeable people are (as already established in the course of telephone interviews) the most important source of product information. Product brochures are also used quite frequently as the basis for selection of specific products. Actual buildings as well as trade fairs and expositions with sample buildings and building products represent an important source of information for many building owners. They are seen as opportunities not only to gain a first-hand impression of specific products, but also benefit from the professional advisory service typically offered in such occasions. Regarding electronic media, there are many CD-Roms produced and generated by various product manufacturers, yet there is a lack of interest on the side of the building owners to put together for themselves CD collections as the source of product information. Likewise, internet is still not acknowledged as an effective information acquisition tool. This circumstance is not only due to the absent or slow internet connections but also an expression of the dissatisfaction with the quality and quantity of information offered in the internet. The typical search scenario involving the internet is when a building owner looks into the homepage of a manufacturer she already knows. Search engines are used when the homepage is unknown or when additional information is desired. None of the building owners interviewed had knowledge of online building product catalogs. 4 CONCLUSION The results of the preceding inquiry permit a few high-level conclusions:

An inquiry into building product information acquisition and processing

619

(i) The generally postulated potential of electronic media (see, for example, Scoones 1997) in view of decision making support for product information acquisition is not exploited in practice. Building catalogs are still the dominant source of information for architects. Both architects and building owners heavily depend on personal conversations with representatives of building product manufacturers and distributors. Electronic media represent de facto a negligible factor in product information search by building owners. (ii) There is a certain contradiction in the views of architects and building owners regarding decision making responsibility. Architects believe to be the main decision making agents regarding the selection of building products. However, this is confirmed by building owners only in the case of industry, office, and large residential buildings. Building owners believe to be the main decision makers in the case of small residential projects and residential renovation projects. (iii) Architects and building owners differ somewhat with regard to both the attributes and the presentation of the product information they search for. Building owners are more interested (particularly in the initial stages of design) in qualitative product features, as well as price and service information. Architects are, in addition, interested in information on details, specifications, technical attributes, and applicable standards. Accordingly, building owners prefer a mixed presentation of product information consisting mainly of photographic and 3-D depictions together with some 2-D and text information. Architects require in addition information included in technical details and tables of product properties. (iv) Both architects and building owners commit to product selection decisions rather late in the design process. Especially in the case of building owners, decisions seem not to be based on extensive “proactive” search, but rather in response to contingencies of the building delivery process. (v) Both architects and building owners display a rather unorganized, often ad hoc product information acquisition behavior. This may be more or less understandable in the case of building owners whose search activities seem to be literally triggered by immediate requirements of the building construction schedule. However, in case of architects, one would expect a more organized, efficient, and long-term product information acquisition and collection behavior. It appears as though the architects have not fully internalized the product information acquisition and product selection activities as important and integrated constituents of their professional self-perception. For practical reasons, the surveys on product information needs and habits have been limited to architects and owners. Given the finding from these surveys, one can expect that the behavior of project engineers or contractors, which are equally important product information users, will again be different. Similar surveys, interviews, and case studies are necessary to learn about the needs of these groups. These conclusions highlight some of the difficult challenges facing those computational systems and electronic environments that intend to support building product selection. In the short term, they may provide more comprehensive search mechanisms and a better presentation of product information. More substantial progress, however, depends on overall improvements in the building delivery process in general. This implies that the provision of computational support for building product selection is

Ework and ebusiness in architecture, engineering and construction

620

more likely to succeed, if it is seen and pursued as part of a larger agenda toward building delivery process support. ACKNOWLEDGEMENT The studies were supported in part by a grant from the Vienna Chamber of Commerce. REFERENCES Amor, R., Newnham, L., Parand, F. and Nisbet, N. 1999. The ARROW data model specification, BRE publication, Watford, United Kingdom. Finne, C. 2003. How the internet is changing the role of construction information middlemen: the case of construction information services. ITcon 8:397–410. Häusler, S.2003. Beschaffung und Verarbeitung von Bauproduktinformation bei Wiener Architekten, Diploma Thesis. Vienna University of Technology, Vienna, Austria. Heinze, 2004. http://www.heinzebauoffice.de/. Hoque, A. and Lohse, G. 1999. An information search cost perspective for designing interfaces for electronic commerce. Journal of Marketing Research 36/8:387–394. Issa, R., Flood, I. and Caglasin, G. 2003. A survey of e-business implementation in the US construction industry. ITcon 8: 15–28. Jain, S. and Augenbroe, G. 2000. The role of product catalogues in design management, CIB W78 Conference on Architectural Management: 271–288. Jain, S. and Augenbroe, G. 2003, A methodology for supporting product selection from ecatalogues, Electronic Journal of Information Technology in Construction 8:381–396. Katz, M, and Byrne, M. 2003. Effects of scent and breadth on use of site-specific search on ecommerce sites. ACM Transactions on Computer-Human Interaction 10: 198–220. Kernstock, S. 2003. Beschaffung von und Umgang mit Bauproduktinformation bei Wiener Bauherren. Vienna University of Technology, Vienna, Austria. Rivard, H., Froese, T., Waugh, L., El-Diraby, T., Mora, R., Torres, H., Gill, S.M. and O’Reilly, T.2004. Case studies on the use of information technology in the Canadian construction industry. ITcon 9:19–34. Rivard, H. 2000. A survey on the impact of information technology on the Canadian architecture, engineering and construction industry. ITcon 5:37–56. Samuelson, O. 2002. IT-Barometer 2000—the use of IT in the nordic construction industry. ITcon 7:1–25. Scoones, A. 1997. Technical information. Automation in Construction 6:23–27. Seiffarth, HP. 1990, Entwicklung einer Osterreichischen Bauproduktdokumentation, Forschungsvorhaben F 1004, Baden, Austria.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Usefulness and ease-of-use assessment of a project management tool for the construction industry B.Otjacques, G.Barrère & F.Feltz Centre de Recherche Public—Gabriel Lippmann, Luxembourg M.Naaranoja University of Vaasa, Finland ABSTRACT: The reasons why the new information technologies diffuse at a low rate in the construction industry are not clearly understood yet. The Information System (IS) science has been confronted to this problem for a long time and the construction specialists can benefit from former research findings. Usefulness and ease-of-use are currently considered as influencing factors in the context of IT adoption. The ‘usefulness’ concept refers to the extent to which using a specific IT tool improves the performance for carrying out some tasks. The ‘ease-of-use’ concept relates to the extent to which the IT tool can be used easily. This paper describes an experiment dedicated to assess the usefulness, the ease-of-use and the intent of use of a project management tool dedicated to the SMEs. The results show that though the perceived ease-of-use of the tool reaches rather high levels usefulness obtains rather poor scores. Moreover, the experience highlights the importance of external variables to influence the intent of use.

1 INTRODUCTION IT adoption in the construction industry is a crucial issue that has been studied by numerous researchers (e.g. Betts, 1999; Flood et al., 2002; Stewart and Mohamed, 2004). Several reasons have been found to influence it at different levels, such as the industry structure, the enterprise resources, or the individual skills. The potential inappropriateness, or at least the limitations, of the current IT tools has also been mentioned as a hindering factor (e.g. Amor and Faraj, 2001). Distinct methodologies were used to obtain these research results, such as surveys (e.g. Doherty, 1997) or case studies (e.g. Rivard et al., 2004). This paper adopts another strategy: the combination of an experimental test and some interviews. 2 IT ADOPTION: THE TAM MODEL The Information Systems discipline has studied the IT adoption problem from a generic viewpoint and several models have been proposed to study the factors that influence the mechanism of technology adoption by individuals. Three of these models are especially

Ework and ebusiness in architecture, engineering and construction

622

famous: the theory of reasoned action (Fishbein and Ajzen, 1975), the theory of planned behaviour (Azjen, 1991), and the technology acceptance model (Davis, 1989). After a review of the IS literature, it appears that Davis’ TAM model (Technology Acceptance Model) is considered as one of the most influent models for studying the final acceptation of a computer-based application (Davis et al, 1989; Veiga et al., 2001). The TAM model aims to predict the degree of acceptation of new technologies by users. It relies on two key concepts: perceived usefulness and perceived ease-of-use. Perceived usefulness refers to the degree to which a person believes that using a particular system would enhance his or her job performance (Davis, 1989). Perceived ease of use, in contrast, refers to the degree to which a person believes that using a particular system would be free of effort (Davis, 1989).

Figure 1. Technology Acceptance Model. According to the TAM model, the use of a new technology is defined by behavioral intentions to use the technical system, which are determined by people attitudes toward using and by perceived usefulness. Perceived usefulness depends on perceived ease-ofuse and on external variables that may refer, for instance, to individual characteristics, the features of the task to be done, or the organisation. The TAM model has been largely used in the context of the adoption of new information and communication technologies, such as the web (Lederer et al., 1998; Moon and Kim, 2001), the intranet (Horton et al., 2001), or the cellular phone (Kwon and Chidambaram, 2000). This model has also been used and validated on several types of populations: administration (Roberts and Henderson, 2000), bank industry (Horton et al, 2001), students (Heilman et al., 2002), hospitals (Rawstorne et al., 2000), and computer industry (Taylor and Todd, 1995). Though TAM model is said to explain only 40% of the actual use (Legris et al., 2003) most of the studies have showed significant relationship between perceived usefulness and intent to use (Lee et al, 2003). Therefore studying the perceived usefulness and easeof-use of a prototype can help to better understand its potential in terms of real usage. 3 THE SOFTWARE TO BE EVALUATED The software to be evaluated is a prototype called BBeLink2 that has been developed within a public research center. This tool aims to facilitate the management of small

Usefulness and ease-of-use assessment of a project management tool

623

construction projects (Otjacques and Post, 2002; Otjacques et al, 2003). Four basic features of this application are under examination in the context of this paper. First, the prototype integrates several tools within a unique application, such as an enhanced electronic messaging system, an organizer, an address book, a project management module (see hereafter), and a conversation visualization module. This feature will be called ‘integration’ in the study. Second, BBeLink2 offers a module dedicated to handle small construction projects. This includes the following features: a standardized description of any project with meta data, a mechanism to invite companies to join the project, and the synchronization of project data. This is called ‘project management module’. Third, BBeLink2 is able to store in unified format some metadata (e.g. project phase, content type, communication medium used, people concerned…) about potentially every communication occurring during the project. On this basis, the module allows to visualize all these information flows in a single user interface. In the experiment, the module is referred to as ‘information flows module’. Fourth, the security issue has been specifically tackled in the prototype. On the one hand, it supports digital signature and encryption. On the other hand, it provides additional features, such as a reliable system to date messages, an automated message receipt handling system, the ability to individually encrypt the documents attached to a message, the encryption of the data stored on the local hard disk… These functionalities are grouped under the ‘security’ label. 4 RESEARCH METHODOLOGY The evaluation of BBeLink2 combines two complementary methodologies: an experimental test with students and some semi-structured interviews with practitioners. 4.1 Experiences with students The purpose of this experiment is to assess the perceived usefulness and the perceived ease-of-use of the four above-mentioned basic features of the BBeLink2 prototype. The test has been applied to a sample of 20 students of a Belgian School of Architecture. They were all students in penultimate year (4th) of the Master in Architecture class. They had already spent significant periods of time as trainee in real offices of architects, which qualif ied them to give some valuable feedback in the context of the experiment. The sample was composed of 10 men and 10 women, on a voluntary basis. Before the actual test, a pre-experimental phase has been carried out with 5 individuals, in order to ensure that the experimental methodology was appropriate and could produce usable results. The experiment was conducted simultaneously by three researchers according to the following schedule. First of all, the researchers explained the context of the experiment and asked the subjects to fill a questionnaire about their degree of familiarity with computers, the Internet, and IT tools. Second, one researcher made a presentation of the BBeLink2 application with a special focus on the four features to be evaluated. The

Ework and ebusiness in architecture, engineering and construction

624

presentation mixed static slides and live demos. In this phase, the subjects played a passive role. Next, the students were asked to actively interact with the software to do some exercises relating to the features to be evaluated. After the exercises the subjects were asked to fill a paper-based questionnaire about their perception of the usefulness (PU) and the ease-of-use (PEU) of the related features, as well as their intent to use them (I). The questionnaire mainly included some Likert scale-based questions having 7 modalities. In order to reduce biases, they have been consolidated into three major opinions as explained in Table 1. Comments are based on consolidated results. Nevertheless, the figures are provided with detailed Likert scale results.

Table 1. Likert scale modalities consolidation. Encoded answer

Retained opinion

+3 and +2

(rather) positive

−1, 0 and +l

(rather) neutral

−3 and −2

(rather) negative

The questionnaire also included a few open questions at its end. The experiment ended with an open discussion about the prototype. The comments were registered by one of the researchers. The total duration of the test was 1 h 45 min. Each session of the test regrouped 4 students. 4.2 Interviews The methodology used was semi-stuctured interview, that focused especially on the four major features—integration, project management module, information flow module and security—to be evaluated. The prototype was demonstrated during the discussion. The session took around one hour. The interviewees all had experience in project management and had been involved in projects in Finland. The positions and experience of the interviewees varied as follows: • an architect that had worked as architect and project manager, over 15 years experience; • a young designer, 3 years experience; • a researcher that had no construction experience but had managed other projects and researched at the time the challenges of construction projects.

5 RESULTS 5.1 Experiment with students The profile of the subjects may be summarized as follows. All of them use a PC for less than 3 years for one third of them and for more than 3 years for the remaining part.

Usefulness and ease-of-use assessment of a project management tool

625

Ninety percents of them use a computer tool at least one time a day. The subjects are thus very familiar with computer use. Moreover, they have a positive attitude towards computers. Indeed, 85% of them think that computers add value to carry out their work and 90% affirm that they are interested by informatics in general. All of the subjects use the Internet at least once a week, for both professional and leisure reasons. Before commenting the results, it must be mentioned that, considering the time constraint of the test, the perceived ease-of-use has been evaluated only for the ‘project management module’ and the ‘information flows module’. This is consistent with the fact that these two features have the most specific user interface. The ‘integration’ and ‘security’ features are completely embedded in the whole environment and their ease-ofuse would be quite difficult to isolate. The usefulness as well as the intent of use has been evaluated for the four features.

Table 2. Evaluation of the ‘integration’ feature. Negative (%)

Neutral (%)

Positive (%)

Perceived usefulness

1.25

56.25

42.50

Intent of use

2.50

20.00

77.50

Figure 2. Evaluation of the ‘integration’ feature. Table 3. Evaluation of the project management module. Negative (%)

Neutral (%)

Positive (%)

Perceived usefulness

6.25

63.75

30.00

Perceived ease-of-use

8.75

28.75

62.50

Intent of use

5.00

25.00

70.00

Ework and ebusiness in architecture, engineering and construction

626

The experimental results are first individually described for each of the targeted features. Then, a global overview will be proposed. The first evaluation relates to the ‘integration’ feature (cf. Table 2). It has received the most positive scores for intent of use and perceived usefulness. This result is not very surprising as it confirms the interest to provide software that integrates features dealing with communication, information diffusion, task management, planning and so forth. The evaluation of the ‘project management module’ has provided more subtle results. The Likert-scale questions (cf. Table 3) shows that less than one third of the subjects find it useful. Nevertheless, the informal discussion has shown that they valuate positively many specific features at a lower level of analysis, such as the ability to disseminate automatically some information about the project or to invite people to join the project.

Figure 3. Evaluation of the project management module. Table 4. Evaluation of the information flows module. Negative (%)

Neutral (%)

Positive (%)

Perceived usefulness

2.50

73.75

23.75

Perceived ease-of-use

0.00

38.75

61.25

Intent of use

0.00

32.50

67.50

Usefulness and ease-of-use assessment of a project management tool

627

Figure 4. Evaluation of the information flows module. Therefore, one might hypothesize that the usefulness of this module is not immediate but that it appears with time. Finally, it is interesting to mention that most of the comments during the informal discussion relate to the advantages of information structuring. For instance, the ability to assign a message to a specific project via dedicated meta data, the harmonized description of all projects, and the automatic creation of a message storage hierarchy when the participation to a project is accepted were especially considered as valuable. The ‘information flows module’ was the most difficult to evaluate. Indeed, it is a completely new feature for all the subjects. This is probably due to the fact that most of the current commercial software do not offer a similar functionality.

Table 5. Evaluation of the ‘security’ feature. Negative (%)

Neutral (%)

Positive (%)

Perceived usefulness

3.75

65.00

31.25

Intent of use

2.50

37.50

60.00

Ework and ebusiness in architecture, engineering and construction

628

Figure 5. Evaluation of the ‘security’ feature. The subjects consider this module as the least useful of the four features under examination. The perceived ease-of-use and the intent of use reaches, however, a rather high score. The informal discussion provides some explanations to this result. The subjects think that this feature has some interesting potential from a theoretical view-point but they fear that it is quite difficult to use it in practice. They mentioned that an efficient usage would require some time that architects lack on the field. The main drawbacks are thus not linked to the user interface itself but to the organizational aspects. This confirms that future developments should focus on increased automation of information flow registering. Encoding of information flows directly from mobile devices is another promising direction to improve the potential of real life applicability of this module. The ‘security’ feature evaluation has also provided some surprising results. Less than one third of the subjects find this feature useful. This could indicate that, despite the large efforts to communicate about this theme, many among the next generation architects do not feel very concerned by this aspect. The informal discussion has highlighted the poor understanding of security issues in the sample population. For instance, the digital signature, the message encryption, or the secure storage of data are confused concepts for the subjects. It is worth reminding that this population had a clear positive opinion about informatics and that it uses computer very regularly. Therefore, one cannot argue that the bad perception of computers limits the awareness of security issues. The limited experience of the subjects may have played a role in this context. It is probable that they were not confronted to computer security issues during their training periods. Nevertheless, in this case, it is also an indicator that senior architects that manage these offices don’t think that computer security is an essential element to which trainees have to be made sensitive.

Usefulness and ease-of-use assessment of a project management tool

629

5.2 Interviews The tool as whole was seen very easy to use but the interviewees did not intend to use it, however. The usefulness could have been greater if one could use only the prototype to manage all the e-mails and project data of the architect company and also the management information of the client. The interviewees pointed out the importance to integrate everything into the same system—all project data should be there. The interface did not either solve the problem of different tools needed to view the attached files. The project management module was seen as useful for an architect—a skilled architect is able to do such things also with a normal tool but it requires more discipline than with the prototype. The information flow module was seen as too complicated. It was difficult to see rapidly how a decision was made. The comments were that this type of information should be somehow in the drawings too. The idea to use symbols in the message to show the type of message was considered as a good idea. Security was seen as very important and one of the claims of a normal e-mail was the security issue. The interviewees again compared the function with a project intranet that can also take care of the security. The interviewees said they would not use the system since the project intranets take care of informing via normal e-mail about changes and such events. The compatibility with the classic e-mail system was seen as a very important factor. In conclusion, we can say that some external variables that the formal questionnaire did not study were used to explain the intent of not using the prototype. In other words, the negative aspects of the prototype that the interviewees pointed out were linked to external variables like the concurrent use of normal e-mail and the difficulties to manage all the projects they had. External variables affected thus the attitudes and even the intent to use the prototype. 5.3 Globalview First of all, one must be aware that potential biases may have influenced the experimental results. As already mentioned, the sample was composed of Belgian students and a small number of practitioners from Finland. The application of the results to professional architects should thus be made careflilly. Nevertheless, the students had a limited but real experience within offices of architects. Therefore, they had already been confronted to real life problems.

Ework and ebusiness in architecture, engineering and construction

630

Figure 6. Percentage of ‘rather positive’ opinion about each feature. The low level of negative opinions expressed by the students for the evaluation of all features may be partly due to the fact that the subjects develop some respect or some empathy toward the experimenters, which hinder them to assign very negative scores. It must be mentioned, however, that the subjects were reminded that they were totally free to express their opinion and that a negative score was as worth as a positive one for the experimenters. Finally, the sample may be considered as a small one, which limits the ability to draw conclusions based on extensive statistics. The comments are thus essentially descriptive and rely both on the answers to the questionnaire and on the informal discussions. Considering those biases, the experimenters consider that a higher importance should be given to the results concerning the perceived usefulness and the perceived ease-of-use than to those about the intent of use. The first conclusion to be drawn concerns the ease-of-use of the prototype. Concerning the two features that were evaluated in the student test (project management module and information flows module), collected data shows that the intended high level of simplicity of the software interface has been reached. The practitioners also judged the tool very easy to use. This indicates the quality of the underlying design strategy, which postulated to offer to the user an interface that mimics the appearance of the most diffused applications (i.e. e-mail). The second conclusion relates to the globally low level of usefulness of all features. This is probably caused by a dual effect. First, the subjects were given little time to evaluate the application. They had no opportunity to carefully reflect on usefulness and their answers were rather impulsive. Second, the prototype probably has weaknesses in terms of usefulness or at least in terms of communicating the usefulness of some of its features. This might also be due to the fact that the perceived advantages of administrative management software are less obvious than those of drawing, computing or design tools.

Usefulness and ease-of-use assessment of a project management tool

631

6 CONCLUSIONS The evaluation has shown that the user interface of the prototype meets the expectation of the subjects in terms of ease-of-use. It also highlighted some weaknesses concerning the usefulness of some features. The discussion confirms the role that usefulness plays for the intent of use of the system. Despite the fact that the methodology does not allow to draw statistically significant inferences, it seem to confirm, however, some components of the TAM model. The interviews also confirm that external variables might play a decisive role in the perception of usefulness and ease-of-use. Indeed, some external factors (e.g. the features of the applications that the users are familiar with) that were neglected in the formal tests appeared to be significant in the open discussion. Similarly, very practical elements may influence the intent of use, such as the ability to run the application concurrently with other ones. REFERENCES Ajzen I. (1991). The Theory of Planned Behavior, Organizational Behavior and Human Decision Processes, 50:179–211. Amor R and Faraj I. (2001). Misconceptions About Integrated Project Databases, Electronic Journal of IT in Construction, 6:57–68, http://www.itcon.Org/2001/5. Betts M. (1999). Strategic Management of IT in Construction, Oxford, UK: Blackwell Science. Davis F. (1989). User Acceptance of information Technology: Systems Characteristics, User Perceptions and Behavioral Impacts, International Journal of Man-Machine Studies, 38(3):475– 487. Davis F., Bagozzi R. and Warshaw P. (1989). User Acceptance of Computer Technology, MIS Quarterly, 13(3):319–340. Doherty JM. (1997). A Survey of Computer Use in the New Zealand Building and Construction Industry, Electronic Journal of IT in Construction, 2:73–86, http://www.itcon.Org/1997/4. Fishbein M. and Ajzen I. (1975). Belief, Attitude, Intention, and Behaviour: An introduction to Theory and Research, Reading, MA: Addison-Wesley. Flood I., Issa R.R.A. and Caglasin G. (2002). Assessment of e-business implementation in the US construction industry, Proceedings of the 4th ECPPM Conference, Portoroz, Slovenia, 9–11 September 2002, pp. 87–94. Horton R., Buck T., Waterson P. and Clegg C. (2001). Explaining intranet use with the technology acceptance model, Journal of Information Technology, 16:237–249. Kwon H. et Chidambaram L. (2000). A Test of the Technology Acceptance Model—The Case of Cellular Telephone Adoption, Proceedings of the 33th Annual Hawaii International Conference on System Sciences, IEEE Comput. Soc. Press, Los Alamitos. Lee Y., Kozar K.A. and Larsen K.R. (2003). The technology acceptance model: Past, present and future, Communication of the AIS 12, No 50:50. Lederer A., Maupin D., Sena M. and Zhuang, Y. (1998). The Role of Ease of Use, Usefulness and Attitude in the Prediction of World Wide Web Usage, Proceedings of the 1998 Association for Computing Machinery Special Interest Group on Computer Personnel Research Conference, Agarwal, R. (Ed.), March 26–28, 1998, Boston MA, pp. 195–204. Legris P., Ingham J. and Collerette (2003). Why people use information technology? A critical review of the technology acceptance model, Information management 40(3): 191–204.

Ework and ebusiness in architecture, engineering and construction

632

Moon J. et Kim Y. (2001). Extending the TAM for a World-Wide-Web context, Information et Management, 38(4): 217–230. Otjacques B. and Post, P. (2002). Construction Project Management: a new concept dedicated to the Small and Medium SizedEnterprises, Proceedings of the 4th ECPPM Conference, Portoroz, Slovenia, 9–11 September 2002, pp. 171–172. Otjacques B., Post P. and Feltz F. (2003). Management of information flows during construction projects, 20th International Conference on IT for Construction CIB W78, 23–25th April 2003, Auckland, New Zealand, pp. 278–285. Rawstorne P., Jayasuriya R. and Caputi, P. (2000). Issues in Predicting and Explaining Usage Behaviors with the Technology Acceptance Model and the Theory of Planned Behavior When Usage is Mandatory, in Orlikowski W., Ang S., Weill P., Krcmar H. et DeGross J. (eds.), Proceedings of the 21st International Conference on Information Systems, Brisbane, Australia, December 2000, pp. 35–44. Rivard H., Froese T., Waugh L.M., El-Diraby T., Mora R., Torres H., Gill S.M. and O’Reilly, T (2004). Case studies on the use of information technology in the Canadian Construction industry, Electronic Journal of IT in Construction, 9:19–34, http://www.itcon.Org/2004/2. Roberts P. and Henderson R. (2000). Information technology acceptance in a sample of government employees: a test of the technology acceptance model, Interacting with Computers, 12(5):427–443. Stewart R.A. and Mohamed S. (2003). Coping strategies to aid effective information technology implementation in construction, Proceedings of the 2nd International Conference on Innovation in Architecture, Engineering and Construction, Loughborough, UK, 25–27th June 2003. pp. 69– 78. Taylor S. et Todd P (1995). Understanding Information Technology Usage: A Test of Competing Models, Information Systems Research, 6(2):144–176. Veiga J., Floyd S. and Dechant K. (2001). Towards modelling the effects of national culture on IT implementation and acceptance, Journal of Information Technology, 16: 145–158. von Linde R.B. (2000). A usability study of construction related IDEFO model, Proceedings of the 3rd ECPPM Conference, Lisbon, Portugal, 25–27th September 2000, pp. 209–215.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Development and implementation of a functional architecture for an e-engineering Hub in construction Z.Ren, C.J.Anumba & T.M.Hassan Department of civil & Building Engineering, Loughborough University, UK G.Augenbroe College of Architecture, Georgia Tech, Atlanta, USA ABSTRACT: This paper presents the conceptual development and implementation of the functional architecture for the e-Engineering Hub developed by the eHUBs project (e-Engineering enabled by Holonomic and Universal Broker Services, IST-2001–34031). The e-Hub is conceived to offer a balanced combination of system based approaches to e-engineering cultures, trust building, enterprise modelling and process sharing, Small and Medium Enterprises (SME) services hosting and reengineering of collaborative workflows. One of the key research objectives is to develop and implement the e-Hub’s functional architecture.

1 INTRODUCTION The emergence of various e-Hubs are changing the traditional approaches of marketing, transaction and collaboration among enterprises. The e-HUBs project aims to develop a new approach to facilitating collaboration among SMEs by offering transparent templates during the engineering collaboration process. Such an e-Hub extends the capabilities of its business partners with joint engineering, knowledge and other resources of individual SMEs by providing brokerage of complementary engineering services. One of the key research objectives of this project is to develop and implement a functional architecture to support the e-Hub’s generic engineering services. To develop the functional architecture, two major research approaches have been undertaken. Firstly, a top-down research approach was adopted to identify an appropriate project planning (PP) platform and functional architecture which allow the users to define projects collaboratively by taking advantage of the engineering services provided by the e-Hub. Some of these research activities include: review of the Technical Annex (TA) which represents the description of work to be undertaken; study of various business, collaborative and engineering e-Hubs, their services and structures; analysis of eEngineering services; and study of prqject planning, process protocol and workflow management systems.

Ework and ebusiness in architecture, engineering and construction

634

Secondly, a bottom-up research approach was adopted through the development of two engineering scenarios in construction to explore the potential engineering services of the e-Hub in project definition and planning process. A number of e-Hub’s generic services were drawn from these scenarios, with consideration of its potential applications in other industries. These scenarios were further extended as testbeds to implement and evaluate the functional architecture and engineering services. This paper presents the research work related to the development and implementation of the e-Hub’s functional architecture. It first reviews the key concepts of workflow management system and addresses the rationale of adopting workflow as the core of the e-Hub; then identifies the ftmctional requirements of the e-Hub; and discusses the development of the functional architecture. Finally, it demonstrates the implementation of the ftmctional architecture with the seismic engineering scenario. 2 WORKFLOW MANAGEMENT The development of the e-Hub is backed by multi-level knowledge and technologies such as collaboration platforms offering shared project workspaces for team building, group communication, project management, portal “store front” functionality for marketing, contract management, process representation, sharing and execution, knowledge capturing and sharing. The two most important theories behind the development of the eHub’s functional architecture are project planning and workflow management. The former addresses the generic PP process and content; the latter provides an innovative and systematic approach to addressing construction work content. This section reviews the key concept of workflow management system and discusses the rationale of adopting workflow to present project plan process. 2.1 Definition In WfMC (2000), workflow is defined as: “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules”. Gerogakopoulos et al. (1995) give a more explicit description of a workflow process. They define a workflow or a process as a collection of activities organised to accomplish some business goals. An activity can be performed by software systems, humans, or a combination of these. In addition to a collection of activities, a workflow may include constraints that influence the order of performing activities as well as information flow between them. A workflow can be defined by three components: process definition, process instance and activity instance. 2.2 Workflow characteristics The essential workflow characteristics are persons, activities, application tools and resources (Marshak, 1994). The roles perform tasks using application tools that provide

Development and implementation of a functional architecture

635

access to various shared information resources. This characteristics model of workflow is shown in Figure 1 (Marshak, 1994). Marshak (1994; 1997) defines the “3Rs” and the “3Ps” of workflow technology: Rules: Workflow systems take various business rules into account. The rules should be maintainable and understandable by business professionals. Routes: A route is strongly coupled to the concept of information logistic that typically supports organisation flow of all kinds of objects including documents, forms and processes. Roles: Information is routed to roles rather than to a particular person. The role in an organisation is a group of people with the required skills and authority. Processes: Business/engineering processes span over organisation units and legacy information systems. Policies: Policies correspond to a normative process model that describes how certain processes should be handled.

Figure 1. Characteristics of workflow.

Ework and ebusiness in architecture, engineering and construction

636

Figure 2. Workflow system architecture and data structure (WfMC, 2002). Practices: This is the way that a work is actually performed in the organisation. 2.3 Workflow Management System Workflow Management System (WfMS) aims to provide computer-based support for the task of workflow management. It supports the specification, execution, and dynamic control of workflows involving humans and information systems (McCarthy & Sarin, 1993). WfMS runs on one or more workflow engines that are able to interpret the process definition, interact with knowledge participants and, where required, invoke the use of IT tools and applications (WfMC, 2000). Figure 2 shows an outline of workflow management architecture. The process analysis, modelling and definition tools facilitate the specification of the components of a workflow as a process definition. The workflow enactment service enacts a process definition by assigning tasks to humans and software systems while also maintaining the constraints between tasks. The workflow control data represents the dynamic state of the workflow system and its process instance, which is managed and accessible by the workflow management system. The workflow relevant data is used by the workflow management system to determine the state transitions of the workflow instance. 2.4 Workflow in the e-Hub Prior (2003) concludes that workflow system provides three major solutions to business and engineering problems: • A unique and systematic approach to model business or engineering processes where the key features involved in the business or engineering processes such as roles, activities, inter dependencies, routes and resources are included in the workflow; • An effective tool to administrate contract management; and

Development and implementation of a functional architecture

637

• An approach to facilitating knowledge management, records management and process monitoring. With regard to the particular research purpose, the concept of meta workflow model is introduced in this study. The workflow contains various meta information necessary to define a project plan. Each activity in the workflow contains all the essential attributes (meta information) addressing all the key issues of this activity. The meta workflow, configured with the generic PP process and templates, is embedded in the e-Hub PP platform to guide users to conduct PP activities. 3 FUNCTIONAL REQUIREMENTS AND FUNCTIONAL ARCHITECTURE Four major engineering functional requirements have been identified for the e-Hub in the User Requirements (UR) of this project. These functional requirements form different levels of the e-Hub services, from project planning, Engineering Service Provider (ESP) selection, contract development, project execution to the completion of the project (Dl, 2003). Given such a wide range of engineering services, the UR particularly emphasises the e-Hub’s role in facilitating project preparation activities to shorten the project starting up period, while preserving and even improving the quality of the group work required for successful project execution. 3.1 The role of the e-Hub in project preparation process As illustrated in Figure 3, the e-Hub should, through its value added services, provide the Client and the ESP with a workspace to define a collaborative work plan during the project definition and planning, and contract negotiation processes. The UR specifies the

Figure 3. The collaborative role of the e-Hub.

Ework and ebusiness in architecture, engineering and construction

638

e-Hub’s role as: “The e-Hub could facilitate process of preparation of project in SMEs proposing electronic templates for the documents, related to various areas of engineering. Development of document templates, especially these containing macros and elements of automation, requires significant effort and specific skills. Preparation of document templates and instruction for filling in the formats as well as consultations in preparation of contractual documentation may constitute a part of the business activities of the eHub.” 3.2 Functional architecture The e-Hub’s functional architecture is developed to achieve these engineering functions (Figure 4). Some key points of the functional architecture are summarised as follows: • The workspace provided by the e-Hub will mainly facilitate collaborative project definition and planning, and contract negotiation between the Client and the ESP. Essentially, the e-Hub workspace will be a generic negotiation platform allowing the users to define, plan and negotiate various project engineering and contractual issues. All these activities will be supported by the related Engineering Web Services (Ren et al, 2003). • To facilitate the project definition and planning, workflows, representing the generic PP process, are embedded in the e-Hub workspace. This PP workflows will guide users to go through every key project definition and planning stage. First, it leads users to define the project charter, address project scope statement, and then define detailed project work statements (PMBOK, 2000). These project work statements address all the key issues for project execution such as project execution plan and schedule, quality plan, riskplan, communication protocol, change management protocol, and resource plan, each guided by a sub-workflow. • Besides the generic PPP workflow, various attribute templates for each of the PP issues are also embedded in the e-Hub. These templates, built based on both theoretical studies and industrial scenarios, include all the key elements which every plan should cover. The negotiation between the Client and the ESP is basically to address these attributes defined in the templates. Also, these templates form the basis for the development of the sub-workflows.

Development and implementation of a functional architecture

639

Figure 4. The functional architecture of the e-Hub. • Meanwhile, a generic negotiation workflow is also embedded in the e-Hub. The enactment of this workflow will guide users through the general negotiation process (e.g. propose, check, modify, re-check, and re-modify). This negotiation workflow is generic to all the PP issues. • Besides the above issues, it is important to note that the workflow requires certain supporting engineering services to be implemented in, or deployed in co-existence with, the e-Hub. For example, spread sheet (a cost estimation tool), GanttProject (a project scheduling tool.) and eLEGAL contract editor (e-contract tool) are adopted in the seismic engineering scenario (discussed below). • Furthermore, the e-Hub provides a transparent and traceable environment allowing users to jointly define, negotiate and modify this meta workflow both graphically and textually. Figure 5 illustrates the PP process by the Client and the ESP conducted in the e-Hub negotiation platform. Based on the work plan defined, the e-Hub will further facilitate the contract negotiation between users. To do that, the e-Hub provides various engineering service contract templates covering different situations users may encounter. Either in the e-Hub negotiation platform or through other online contracting system (e.g. eLEGAL Contract Editor), users can negotiate and specify the details of a contract. All the related work statements (e.g. diagrams and reports) will be integrated in the contract as attachments.

Ework and ebusiness in architecture, engineering and construction

640

4 IMPLEMENTATION OF THE FUNCTIONAL ARCHITECTURE The implementation of the e-Hub’s functional architecture involves many important issues. This section discusses the development of generic PP workflows and the supporting engineering services in a seismic engineering scenario. In this example, the Client and the ESP need to collaboratively define a work plan for the outsourcing of seismic risk analysis service on the e-Hub platform. There are three major aspects to be addressed in this case: project description and cost estimate, project execution and schedule and contract negotiation. This section takes the project execution plan and schedule as an example.

Figure 5. Project planning conducted in the e-Hub negotiation platform.

Development and implementation of a functional architecture

641

Figure 6. Project execution plan and schedule WF.

4.1 Development of generic PP workflows As illustrated in Figure 4, generic PP workflows form the core of the e-Hub’s functional architecture. These workflows codify the logic of a process that enforces collaborative project definition and planning conducted in the e-Hub platform with the involvement of all the project partners. Altogether, three workflows and related attribute templates are developed in the seismic engineering scenario with each representing a key phase of PP process. Figure 6 illustrates the workflow which defines project execution plan and schedule for the seismic engineering scenario. Table 1 presents the attribute template for this workflow.

Ework and ebusiness in architecture, engineering and construction

642

Table 1. Attribute template for project execution plan and schedule workflow. Item

Attributes to address

Activities

• ID No. • Title • Description • Responsibility • Pre-conditions • Post-conditions

Dependencies

• Precedent activity • Successor activity

Duration

• Time

Deliverables/Inputs

• ID no. • Title • Description • Responsibility • Date

Milestones

• ID no. • Title • Description • Date

4.2 Supporting engineering services Although the project execution plan and scheduling workflow and the related attribute template specify the process of defining project execution plan and schedule, a project planning and scheduling platform (i.e. scheduling service) is necessary for project participants to undertake detailed task scheduling. This is because the e-Hub is not designed as a specific task scheduling tool. External project scheduling services need to be incorporated with the e-Hub engineering services (Figure 7). Some of the commonly used project scheduling tools could be adopted such as MS. Project, Primavera, Barchart, GanttProject, task scheduling whiteboard and other visualized PP tools (e.g. PP JAWE and JDPG).

Development and implementation of a functional architecture

643

Figure 7. Scheduling service incorporated with the e-Hub engineering services. In this testbed, project planning and scheduling starts when all the potential activities to be performed have been identified by project participants in the e-Hub platform. They then enter into task scheduling, either offline or through a task scheduling platform that could be either recommended by the e-Hub or by participants. In this testbed use is made

Ework and ebusiness in architecture, engineering and construction

644

of a collaborative task scheduling platform. For this, GanttProject (URL1) is adopted as the scheduling platform due to its particular advantages such as: • GanttProject is written in java; thus it can be run in any operating system; • GanttProject is easy to use. The task scheduling process in GanttProject follow the same process defined in Workflow 2; and • GanttProject uses an XML file format to save the schedule defined, which can be exported into HTML web pages. This allows different project participants to edit the same project schedule online. For example, the Client defines its tasks and save the schedule into the eRiskZone database; Geodeco and other partners can open the schedule from the database and improve it, then save it back to the database. The scheduling activities conducted in GanttProject are integrated through e-Hub enacted workflow (e.g. define tasks, identify dependencies and define duration). Depending on the project, schedule requirement and team members, these activities could be integrated either tightly or relatively loosely. All the nptes and comments made by each participant during the collaborative definition process are recorded in the scheduling file. Project participants can also communicate and negotiate the schedule through the e-Hub basic collaboration platform. Furthermore, the e-Hub also provides a PP and scheduling whiteboard, which allows project participants to discuss any particular aspect of task schedule or of any issue of the project plan in a synchronous session through live diagrammatic communication. This is particularly useful for the projects adopting the traditional task scheduling tools such as MS. Project and Primavera which do not support online scheduling and negotiation. Through this whiteboard, the detailed task schedule negotiation is further integrated. 4.3 Implementation of PP workflows The generic PP workflows need to be translated into XPDL format so that they can be embedded in the e-Hub platform. The extended JaWE developed by European Dynamics (one of the partners of the e-Hubs project) is adopted to design the workflows (URL2). Figure 8 is the screenshots of the project execution plan and schedule workflow defined in JaWE. Many important conceptual and technical issues are involved in the workflow design and implementation process, which are vital for the successful implementation of the eHub. This testbed has successfully solved a few such problems such as: • The achievement of contract negotiation tracking and annotation function, • The data authority management in the workflow, • The call upon of external software (e.g. GanttProject and eLEGAL contract editor, URL3) in an workflow activity, • The data transferring between workflow and document templates in database, and • The adoption of sub-flows to allow an activity calls other workflows or sub-processes.

Development and implementation of a functional architecture

645

5 CONCLUSION Supported by Web-hosted engineering services, the developed e-Hub’s functional architecture provides users with a unique workspace to conduct project planning and contract negotiation. Users are able to plan the details of the work to be outsourced collaboratively and negotiate the contract with the support of

Figure 8. Workflow defined in JaWE. the generic PP workflow and attribute templates embedded in the e-Hub workspace. Such a functional architecture is innovative in terms of the approach it provides to facilitate collaborative planning, and the generic PP workflow management system and document templates embedded in the system. The generic engineering services supported by this functional architecture will enable the e-Hub to act as a universal broker to facilitate the engineering outsourcing work in different industries. Above all, the overall e-Hub’s functional architecture can be summarised as: • The advanced technologies for Internet based communication and web hosted collaborative engineering form the baseline of the core of the prototypical e-Hubs. • On top of this core, incremental layers of additional services are built in a holonomic systems sense. Each service system offers dedicated e-engineering functions at increasing subsystem scales: individual, collaborative group, and e-engineering team. • The e-Hub is configured by offering transparent collaboration templates to each of these systems. Its services is defined and developed for process sharing and configuration based on the process templates for eifective collaboration. The e-Hub also supports

Ework and ebusiness in architecture, engineering and construction

646

necessary and adequate levels of knowledge capture and sharing, provides SME backoffice engineering tool support and fosters trust building, contract management and marketing relationships. • The development of the e-Hub is done with open and reusable middleware components and deployment of existing best of breed service components through a franchise model of web hosted services. The system approach to the transparent hosting of these services is based on open back end architectures of meta product and process models of e-engineering scenarios.

ACKNOWLEDGEMENTS The e-Hubs project is supported by the European Commission under the IST programmed (Contract no: IST-2001–34031). The authors would like to acknowledge the financial support of the European Commission, and record their appreciation to the eHubs project partners for their contributions to this study. REFERENCES Gerogakopoulos D., Hornick M., Shet A., 1995. An overview of workflow management: form process modelling to workflow automation infrastructure. Distributed and parallel databases, 3(2):119–153. McCarthy D.R., Sarin S.K., 1993. Workflow and transaction in concert. Bulletin of the technical committee on data engineering, 16N2-IEEE, June, special issues on workflow extended transaction systems. WfMC, 2000. Proposal for an asynchronous HTTP binding of Wf-XML. Workflow management coalition. Future Strategies Inc. WfMC, 2002. The Workflow management coalition workflow standard, Workflow process definition interface—XML Process definition language. Workflow management coalition. Future Strategies Inc. Prior C, 2003. Workflow and process management. In Fischer L. (ed.), Workflow handbook 2003. Future Strategies Inc., pp. 17–25. Project management institute, 2000. A guide to the project management body of knowledge (PMBOK). Project Management Institute Inc. Ren, Z., Anumba, C.J., Hassan, T.M., 2003. D5.1: Functional architecture of the e-Hub. e-HUBs project deliverable. IST project: (IST-2001–34031). Ren, Z., Anumba, C.J., Hassan, T.M., 2004. D5.2: Set of working e-engineering services dedicated for seismic engineering demonstrator. e-HUBs project deliverable. IST project: (IST-2001– 34031). Ren, Z., Hassan, T.M., Anumba, C.J., Augenbroe, G., Mangini, M. 2004. e-contracting for the eengineering hub, a case study in the construction industry. The 5th IFIP working conference on virtual enterprises, Toulouse, France. Shevchenko A., Horvath I., Vergeest J., 2003. D1: Formal requirements specification for e-HUBs. e-HUBs project deliverable. IST project: (IST-2001–34031). Technical Annex-1, 2001. e-Engineering enabled by holonomic and universal broker services (eHUBs), description of work. IST project: (IST-2001–34031). URL 1: http://ganttproject.sourceforge.net/

URL 2: http://elf.eurodyn.com:8080/edos/index.do

Development and implementation of a functional architecture

647

URL 3: http://cic.vtt.fi/projects/elegal/public.html

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Legal and contractual issues—are they considered in RTD achievements M.A.Shelbourn, T.M.Hassan & C.D.Carter Department of Civil and Building Engineering, Loughborough University, Loughborough, UK ABSTRACT: One of the main reasons for using information and communication technologies in the construction industry is to increase the efficiency and accuracy of communications. The use of ICT in a business such as construction is a good example where smart organisations are commonly used for any number of different projects. This paper uses the construction industry as an example to highlight whether the legal and contractual challenges of using ICT have been addressed in IST funded projects of the EU. Communications generally operate without contractual support, resulting in a number of potentially serious legal implications— such as validity of contract notices, ownership of data and intellectual property rights. This paper reflects on the collaborative working technologies being applied in a virtual organisation (VO). Here the SO example is the construction industry but many of the issues and concepts can be used in many different domains. The impact of the legal and contractual issues is discussed; with many of the findings from the EU funded research projects eLEGAL and ICCI being used to show how these issues can be addressed.

1 INTRODUCTION One of the main reasons for using information and communication technologies in the construction industry is to increase the efficiency and accuracy of communications through collaborative systems. The use of ICT in a business such as construction is a good example where virtual organisations are commonly used for any number of different projects. This paper uses the construction industry as an example to highlight whether the legal and contractual challenges of using ICT in collaborative systems have been addressed in IST funded projects of the EU. Communications generally operate without contractual support, resulting in a number of potentially serious legal implications—such as validity of contract notices, ownership of data and intellectual property rights. Effective use of collaborative systems are vital in the construction industry because of the large number of project participants, often being geographically dispersed. Studies have highlighted the problems inherent in construction communications. These include inappropriate modes of communication, (i.e. document formats, insufficient infrastructure etc), organisational frameworks that restrict intra-organisational communications and

Legal and contractual issues-are they considered in RTD achievments

649

adversarial contractual relationships which inhibit inter-organisational communications. Information technologies—or information and communication technologies—as they are now referred to have been applied in the construction domain for many years in an attempt to improve communications through more efficient information transfer. These technologies were initially intended to speed up the transfer of data, and possibly provide ‘reusable’ data to avoid rekeying. The introduction of information and communication technologies is not easy. The implementation of new systems produces problems, ranging from technical limitations to cultural and social issues. These problems have limited both the uptake of the technology and their effectiveness. Many of these barriers have been addressed through the definition of standards, recognition of training requirements and change management processes, with varying degrees of success. Further work is needed in many of these areas, but a new focus has emerged as a result of the changing use of information and communication technologies, the legal and contractual issues surrounding their provision and application. 2 LEGAL AND CONTRACTUAL ISSUES AFFECTING ICT IN CONSTRUCTION 2.1 Validity of contract notices The collaborative nature of construction and engineering projects is reflected in the standard forms of contract, for example the use of the JCT suite of contracts in the UK is prevalent on construction projects (JCT 1998). By examining standard construction contracts in several EU countries including Finland, France, Germany, Italy, the Netherlands, Slovenia and the UK it was determined that these contracts typically contain obligations on the parties to communicate with one another by serving and receiving specific formal notices (eLEGAL 2001, ICCI 2002). In order to be contractually valid (and therefore effective) some of these notices are required to be served ‘in writing’, but in UK law it is still unclear whether an email, or the posting of data to a project website, satisfies the requirement that something be ‘in writing’ (eLEGAL 2001). As a minimum, it will be necessary to introduce clauses into contracts which provide that any communication, be it of a notice, certificate or programme, etc., may be made electronically and which provide that the term ‘writing’ includes electronic communication (eLEGAL 2001). 2.2 Legal admissibility In the EU construction sector any kind of document has the potential to be legally admissible. A document for the purposes of the law of evidence is very widely defined as ‘anything in which information of any description is recorded’. Therefore potentially any type of electronic communication will be legally admissible in the event of a dispute (GOODWIN 2001). Legal admissibility should not be confused with contractual validity. If a document is legally admissible this means that it will be admitted in evidence, i.e. it will be permitted for it to be put before a court for its consideration. The rules on admissibility are a matter of law and it is not open to the parties to a contract to specify

Ework and ebusiness in architecture, engineering and construction

650

what will and will not be admissible. That is a matter for the court to decide. However, it is open to parties to specify requirements for contractual validity (such as the requirement that a notice be in writing) (TESEI ET AL. 2001). 2.3 Agreements with technology suppliers Depending on the level of the technology employed on a project, the technology provider will play a vital role in its success. Where the use of technology is extensive (for example where a third party provides the design, maintenance and hosting of an on-line project collaboration tool, usually an ‘Application Service Provider’ (ASP)) the performance of the other members of the project team will greatly depend on the performance of that technology supplier (VALIKÄNGAS & PUTTONEN 2002). Therefore, careful attention needs to be given to the question of who is liable for any failure on the part of the technology supplier, as this will inevitably have a knock-on effect on the performance of other members of a project team (JUNGEMANN-DORNER 2002). Agreements with technology suppliers need to be carefully drafted to ensure that such liability is properly identified and allocated appropriately. 2.4 Agreements between project team members in relation to the use of technology The use of new technology changes the way in which project team members communicate. Therefore, there may be a need to formalise the way in which this communication takes place (eLEGAL 2001). This may range from simply having an agreed project-wide e-mail protocol to providing addenda and amendments to main contracts and designers’ appointment contracts to regulate the use of other kinds of ICT (SHUM 2002). On larger projects there could even be a contract specifically written for the use of ICT. This contract could be the ICT contract that was developed by the eLEGAL project (eLEGAL 2002). The issue here is really one of good practice. Any party wishing to rely on any document, whether electronic or not, can increase the weight likely to be given to such a document by a court of law through demonstrating good practice in its creation and storage. 2.5 Ownership of and access to data With the increasing use of web-based project collaboration, increasing amounts of data will be held centrally on project servers, which may be hosted by a third party. It is important to address who is entitled to have access to this data—not just project communications, i.e. correspondence, drawings, etc., but also to ‘meta-data’ which is ‘data about data’ and which can provide information about any project team member’s access to, and use of, the project information (SHELBOURN ET AL. 2002). Where there is extensive use of ICT on a project this issue can and should be addressed in the contracts between the various project participants (eLEGAL 2002).

Legal and contractual issues-are they considered in RTD achievments

651

2.6 Intellectual Property Rights (IPRs) For Architectural, Engineering and Construction businesses copyright is the most important IPR protected by law. In the UK, like many other EU countries no formality such as registration is needed in order for copyright to arise, it is automatically created along with the material itself, e.g. architectural drawing, a model or even the building itself. In the UK the Copyright Designs and Patents Act 1988 (CDPA) gives the owner of the copyright in a work exclusive rights in relation to it including the right to copy it and adapt it. Section 17(2) of the Act states that copying means reproducing the work in any material form including storing the work by electronic means. The implications for project team members using ICT are clear—downloading copyright material is a potential infringement. However, by providing designs for use on a project it is likely that designers will be granting an implied licence to members of the project team to use them for the purposes of the project. Furthermore, the designer’s appointment will usually deal with this explicitly and contain provisions about copyright in the designer’s designs. Typically, the copyright vests in the designer, but the employer is granted a licence to use the design in connection with the project in question (ALIVE 2002). With Design and Build (turnkey) Contracts, contractors’ designs are typically owned by the contractor, with the employer having a licence to use them for the purposes of a project. In cases where the contractor does not carry out the design (i.e. an architect does so on behalf of the employer), the contractor is not allowed to use the designs for any purposes other than the completion of the works (ALIVE 2002). Designers have expressed concerns about the effect that the Internet and especially online project collaboration tools will have on their copyright in their designs. In the EU, the same legal protection is afforded to those seeking to prevent unlawful copying electronically as in the paper world, but the ease with which unlawful copies can be made is dramatically increased when material is made available electronically (ALIVE 2002). The increased use of electronic transmission of copyright material therefore increases the problem of detection of misuse and enforcement, rather than introducing any novel legal issues. 2.7 Data protection EU legislation has meant that the way in which an individual’s data can be collected and processed is now regulated by statute. This legislation includes: The common law duty of confidentiality; The Human Rights Act 1998; The Data Protection Act 1998; and The Freedom of Information Act (GUARDIAN, EPUBLIC 2003). The use of ICT on a construction project will often involve the processing of an individual’s personal data, for example, the collection of databases of individuals contact details. With few exceptions, the permission of such individuals must be received before their personal data can be processed. Systems need to be put in place to ensure that any necessary permissions are gained from individuals whose data is to be processed, and to ensure that adequate security is provided in relation to that data (DATA PROTECTION ACT 1998).

Ework and ebusiness in architecture, engineering and construction

652

3 METHODS AND TOOLS TO ENABLE LEGAL AND CONTRACTUAL VALIDITY To enable many of the legal and contractual barriers for ICT use in construction projects, research sponsored by the EU has produced a number of simple to use tools to enable project based businesses to realise legal and contractual validity of ICT in their projects. The main track of much of this research is to provide project based businesses (mainly in the construction sector) with a framework for specifying legal conditions and contracts to enable a legally admissible (exclusive) use if ICT in their projects (eLEGAL 2001a). The results of the research have provided a clause library, a collection of clauses to support the application of ICTs to business processes, including provisions for different types of project and the variations in national legal and regulatory frameworks across Europe. The clause library provides the knowledge base to a contract configuration tool. This is software that is able to produce ICT contracts for different forms of project based business for construction projects in particular. The various parties defining and negotiating the ICT contract can do so in a collaborative environment known as a ‘virtual negotiation room’ (VNR). The VNR allows a user of the contract configuration software to download the latest version of the contract, edit it and return it to the VNR over the Internet. The VNR also requires the user to digitally sign each submission to avoid any chance of argument over who sent what and when it was sent. These type of tools have been developed to help project based businesses in their dayto-day activities. GEODECO, (an Italian Geotechnical engineering company) has used these types of tools as part of their collaboration platform (also provided from EU funded research ISTFORCE). The combination of the legal and contractual compliance tools with their collaboration platform has meant that setting up and running virtual organisations (VOs) to tackle a business problem has become much easier (MERZ & MANGINI 2002). A graphical representation of a typical VO is shown in Figure 1. A typical scenario would involve a user inputting coordinates of a site (by clicking on an interactive GIS map) where they wish to build a structure, and inputting all available information about the soil characteristics and the structure typology. The GEODECO system provides, free of charge, results of a simplified analysis which is useful to establish the real need for a more sophisticated analysis that will be performed off-line through human intervention by experts in the field. Traditionally, a standard contract adapted to the needs of the specific project would be sent to the client for signature. The client would then sign it and send it back to the design office at GEODECO. This process is now facilitated electronically by using the contract configuration and VNR tools described above. Using these tools it is possible for the two parties to negotiate and digitally sign every clause of a consulting contract, and still ensuring that remote consulting activities do not differ from traditional ‘contact-based’ consulting. Digital signatures on the relevant documents, also ensure the necessary tracking and consequent liability from the consultant’s side. All contractual issues are finalised using these types of tools in a very short time, which is crucial for services which may be required at very short notice.

Legal and contractual issues-are they considered in RTD achievments

653

Figure 1. Graphical representation of the GEODECO’s use of the eLEGAL tools for online contracting (MERZ & MANGINI 2002).

4 ARE THE LEGAL AND CONTRACTUAL ISSUES BEING IMPLEMENTED IN IST RTD ACTIVITIES Having described how legal and contractual validity for transactions using ICT on construction projects can be achieved using the tools and methods described in section 3, the question to now consider is: are these or similar tools being implemented in RTD activities in the construction domain. Research has focused on analysing and synthesising the results of EU and National research projects providing collaborative working technologies to all project stakeholders on construction projects. A more targeted study within the ICCI project (ICCI 2003) has

Ework and ebusiness in architecture, engineering and construction

654

determined whether 8 key legal and contractual issues are being considered in RTD tools and software. The 8 key issues are: 1. Electronic/digital signatures—these allow a recipient of a piece of information to know when the information arrived and who has sent it, and to check whether the information has been changed since it was sent; 2. Digital notaries—these provide a time stamping service, proving the existence of a piece of information at a particular time. These are often used in conjunction with an electronic/digital signature; 3. ICT contracts—these describe the ICT use and supporting environment in which all parties involved in a project must comply with to enable the effective use of ICT; 4. ASP contract—these are contracts between an ASP and a client, and the ASP and the other stakeholders involved within a project. The ASP sets up and manages services on behalf of the client, providing facilities and functionality for all project participants; 5. End user licences—these are determined by the ASP and the end users of the ASP’s services. They typically contain information on permitted use of the ASP’s services by the end users, a method of granting access to the services, training for users, IPR and confidentiality conditions, and limits on liability; 6. IPR issues of information—this describes the rights to the information contained within the project for the different stakeholders involved within the project. Many different levels of rights to access will exist that must be managed by the ICT contained within the project; 7. AEC objects—the increased use of ‘object’ technology within construction projects has raised a number of legal and contractual issues. These include ownership, access, change rights, accuracy and management of these objects; and 8. Legal infrastructure—the legal and contractual issues highlighted above need an infrastructure associated with them to enable them to be achieved. To determine at what level each of these legal and contractual issues has been integrated into RTD developments a number of projects have been recognised as appropriate for this purpose. There are 7 EU funded and 2 national funded projects for consideration. Each of the projects were given a score of between 0 and 4 for their recognition and use of the legal and contractual aspects in their developments. The scoring levels were: 4 deployed in the industry/commercial context 3 prototyped/RTD demonstrator 2 made a contribution to the research area 1 studied/conceptually considered 0 not addressed A matrix was devised to show the legal and contractual issues along the top with the 9 projects down the side. The individual scores are shown in the central cells of the matrix. The matrix can be seen in Figure 2. The results are also shown in Figure 2, and more detailed information on the matrix can be found in ICCI (2003). The implications of the results can be summarised as: – The AEC objects issue was the first in the list of resources dedicated to it by the projects, as this was the issue that had the highest scores in the matrix;

Legal and contractual issues-are they considered in RTD achievments

655

– There were tools and methods that had been ‘deployed in the industry/commercial context’ in 3 of the issues, electronic signatures, ICT contracts, and ASP contracts. In the ASP contracts issue there were three different deployments from three different projects studied; – Although the legal infrastructure issue was ranked second in the results, along with ASP contracts, there was no deployment in the industry/commercial context scores, with only a single prototype/RTD demonstrator being developed by of the projects. This is immediately an issue that requires further study; – Towards the end of the results came the ICT contracts and IPR issues of information issues. They were ranked 5th equal. However in the ICT contracts there is an industrial deployment from one of the projects and 3 RTD demonstrators/prototypes, so although not many projects addressed this issue, those that did developed technology that can be readily used by the industry; – The issue of the use of end user licences was ranked 7th in the results, but there was an RTD/ prototype made available by one of the projects; – The digital notaries issue was the one with the least score, but again there was an RTD/demonstrator available for organisations that wish to begin to trial its use in their day-to-day workings with electronic transactions.

Figure 2. Matrix showing the areas where the legal and contractual issues have or have not been addressed in the projects associated with the ICCI project.

Ework and ebusiness in architecture, engineering and construction

656

To summarise the results have shown that there is a commercial product available for the use of electronic signatures, ICT contracts, or ASP contracts directly from the projects studied in this exercise. There are prototypes available for users to test and possibly integrate into their day-to-day working in all of the other legal and contractual issues studied. The number of projects that carried out research into each of the legal and contractual issues differed significantly. For example the area of legal AEC objects although researched by all projects, does not have commercially available tools to use to overcome the legal barriers to the wider uptake of AEC objects (ICCI2003). However, it should be noted that even though there are commercial products available for all of the legal and contractual issues researched, the development of a complete legal framework to enable the use of ICT on construction projects has yet to be fully realised. This is one of a number of areas that requires further research. These areas are discussed in the next section. 5 FUTURE RTD ACTIVITIES FOR LEGAL AND CONTRACTUAL ISSUES The acceptance of the legal accountability of electronic transactions is an area where all stakeholders of the project have to be in agreement. Having transactions that a user has trust and confidence in the use of ICT for electric transactions will be a real benefit to the project. This can in turn lead to increased quality and profitability of the finished product. Assessing and fully addressing the IPR, security, privacy, and ownership implications of electronic data will have to be defined in contractual aspects of the project. Figure 3 shows a graphical representation of the different activities

Figure 3. Roadmap of legal and contractual governance for ICT in collaborative working.

Legal and contractual issues-are they considered in RTD achievments

657

needed at different timescales to enable full legal and contractual governance for ICT and collaborative working. The development of comprehensive online smart contract configuration tools to enable the editing of contracts from the negotiation to the final process of digitally signing the contract will play a major part in addressing the IPR, security, etc issues. These tools should also provide support for assigning and defining contractual liabilities, including the liabilities of the partners in relation to the accessibility of electronic data as part of these contract definition tools. It is widely acknowledged that object-model based ICT will be the flavour of future ICT developments for the construction industry, (ROADCON 2003) however, the legal issues of using these ‘objects’, i.e. their specification in the ICT contract for example, still needs to be further researched to be fully understood. Such legal issues would include the ownership of the object, stakeholders who have the rights to view, manipulate or delete the objects. Virtual identity management is the next progression to allow document validation, in such a way that it is possible to guarantee the author identity of a document. This ensures that no changes have been carried out to the original when they should not have been. The identification and clarification of the benefits of addressing the legal and contractual aspects of using the digital signature and notary technology in any country is also a big challenge for future research. Digital rights management (DRM) systems that restrict the use of digital files in order to protect the interests of copyright holders are also needed. DRM technologies should be developed to control file access (number of views, length of views), altering, sharing, copying, printing, and saving. These technologies may be developed to be contained within the operating system, program software, or in the actual hardware of a device. Trust models need to be used to assign different levels of trust to different stakeholders within the project dependent upon the nature of the transaction taking place between the stakeholders using the ICT. Transaction monitors should be used to monitor the flow of electronic information and documentation to ensure that they meet the predefined levels of legal validity, e.g. it conforms to the terms of the clauses set out in the ICT contract, the level of security, e.g. the level of digital signature required, and the amount of trust from the party that has sent the information. 6 CONCLUSIONS A barrier to the strategic use of ICT on construction projects was identified as being the legal and contractual issues by the eLEGAL project. Studies identified that the legal and contractual use of ICT was not covered by in traditional construction contracts in a number of EU countries. A brief summary of the legal and contractual issues that require studying to enable the strategic use of ICT to continue has been described. Solutions developed by the eLEGAL project that include tools to enable the online negotiation and signing of contracts by stakeholders in a construction project, with no legal experience have been described. Research into the use of these tools has also been discussed. The results show that solutions (some of them being commercial products, but many being RTD

Ework and ebusiness in architecture, engineering and construction

658

demonstrators/prototypes) are available to the industry to enable the legal and contractual issues identified to no longer be a barrier for certain aspects of ICT use on construction projects. From the conclusions of these results a number of new research areas have been identified. These include the development of complete legal infrastructure that incorporates virtual identity management, transaction monitors and trust models as new research areas to compliment the ones already identified and described in this paper. ACKNOWLEDGEMENTS The authors wish to acknowledge the European Commission for their continued support, and our gratitude and appreciation to all the ALIVE (IST-2000–25459), eLEGAL (IST1999–20570) and ICCI (IST-2001–33022) project partners for their contributions to these projects and this paper. More information on the eLEGAL and ICCI projects results, including document and software downloads can be found at their website: http://cic.vtt.fi/projects. REFERENCES ALIVE (2002). Deliverable D13: Intellectual & Industrial Property Rights Legal Issues report. ALIVE: Advanced Legal Issues in Virtual Enterprises, IST-2000–25459, pp. 38 Data Protection Act (1998), see http://www.hmso.gov.uk/acts/acts1998/19980029.htm. eLEGAL (2001). Deliverable Dll: State-of-the-art Assessment, eLEGAL: Specifying Legal Terms of Contract in ICT Environment, IST-1999–20570 eLEGAL (2002). Deliverable D31: Specification of ICT support tools. eLEGAL: Specifying Legal Terms of Contract in ICT Environment, IST-1999–20570 Goodwin, P. (2001). Effective integration of IT in construction—a partners in innovation project final report. The Building Centre Trust Guardian, ePUBLIC (2003). Get those staff up to standard, article published in the ePUBLIC supplement of the Guardian newspaper in the UK, 8th October 2003, pp. 11–18 ICCI (2002). Deliverable D41: State-of-the-art review on legal and contractual issues for ICT in construction, ICCI projectIST-2001–33022 ICCI (2003). Deliverable D42 (issue 2): Identification of the potential Legal and Contractual gaps and problems within the cluster projects, ICCI project IST-2001–33022 Joint Contracts Tribunal (JCT) (1998). Standard Form of Building Contract, 1998 Edition: RIBA Publications, London Jungemann-Dorner, M. (2002). Open Contracting TransActions in the New Economy (OCTANE project). Proceedings of the eLEGAL 2002 European Conference on Legal Aspects of ICT Application in Project-Based Business, 3–4th October 2002, Loughborough University, UK Merz, M. & Mangini, M. (2002). eContracting and remote engineering consulting services. Proceedings of the eLEGAL 2002 European Conference on Legal Aspects of ICT Application in Project-Based Business, 3–4th October 2002, Loughborough University, UK ROADCON (2003). Deliverable D52 ‘Construction ICT Roadmap’ from the ROADCON project— IST-2001–37278 Shelbourn, M., et al. (2002). A review of the legal and contractual issues for the use of ICT in construction. Proceedings of the eLEGAL 2002 European Conference on Legal Aspects of ICT Application in Project-Based Business, 3–4th October 2002, Loughborough University, UK

Legal and contractual issues-are they considered in RTD achievments

659

Shum, A. (2002). Legal Concerns by Hong Kong Building Professionals in Adopting e-project Management. Proceedings of the eLEGAL 2002 European Conference on Legal Aspects of ICT Application in Project-Based Business, 3–4th October 2002, Loughborough University, UK Tesei, G., et al. (2001). Electronic Contracting in the Construction Industry. Proceedings of the eBusiness—eWork Conference, Venice, October 2001, pp. 595–601 Valikangas, P. & Puttonen, J. (2002). End User View of ICT and Contracts in Virtual Enterprises. Proceedings of the eLEGAL 2002 conference, Loughborough, October 2002. Proceedings of the eLEGAL 2002 European Conference on Legal Aspects of ICT Application in Project-Based Business, 3–4th October 2002, Loughborough University, UK

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Modeling of ERP system solutions for the construction industry M.O.Tatari Purdue University, West Lafayette, IN, USA B-Y.Ryoo Florida International University, Miami, FL, USA M.J.Skibniewski Purdue University, West Lafayette, IN, USA ABSTRACT: Enterprise resource planning (ERP) is considered to be one of the greatest innovations of the 1990s in information technology. Yet, compared to other industries, the significant impacts of ERP have not been realized in the construction industry. Although some large construction companies have implemented certain modules of ERP, there are few companies that have integrated their project-based information systems and their enterprise information systems. Also, it is observed that there are barely any installations in the mid-market construction companies. The successful diffusion of ERP in the construction industry can have substantial benefits and solutions to integration problems in the industry Building on an assessment of current diffusion of innovation literature, a model of ERP adoption in the construction industry has been developed. With this model, it is aimed to identify the factors that affect the adoption of ERP in the construction industry.

1 INTRODUCTION The efficiency and productivity of the construction industry is crucial for the whole economy Nevertheless, as it is studied enormously in the literature, the construction industry has many hindered problems, such as the fragmented and the inefficient nature, and the technology-averse practices. The construction industry has not been successful on combining high quality with productivity, and still, most of the decisions are made based on the lowest cost instead of quality, sustainability, safety, and value. Most importantly, the construction industry has not been able to realize the information integration fully, which influences productivity and quality negatively While all these problems still persist, there are some efforts to change. As a matter of fact, many governmental institutions, industrial and academic organizations, and construction firms, in US and worldwide, are investing in research to improve the performance of the industry. In many of these research efforts, the problem of integration issue is addressed and some solutions are proposed.

Modeling of ERP system solutions for the construction industry

661

On the other hand, the manufacturing industry has had the same problems of integration, but was able to solve it with the aid of integrated information systems, such as enterprise resource planning systems (ERP). ERP systems are considered to be the greatest information technology innovation of the 1990s in the corporate use (Davenport 1998). Solutions offered by tier 1 ERP vendors such as SAP, Oracle and PeopleSoft, have been installed by the largest manufacturing firms. According to a recent study, it is evidenced that nearly 19% of organizations across all industry sectors have installed ERP software, with the manufacturing sector leading the trend (Computer Economics 1999). In another study, 70% of Fortune 1000 companies were reported as having or in the process of implementing an ERP system (Hoffman 1998). ERP systems offer real-time integrated information systems, which could solve some of the information integration problems in construction firms. As a matter of fact, major ERP vendors, such as SAP, Oracle and PeopleSoft, have already tailored their software to fit the construction market, and they are promising to solve these hindered integration problems. 1.1 Enterprise resource planning ERP systems can be defined as integrated information systems (Duplaga and Marzie 2003). These systems integrate all the information flowing through an enterprise, including people across functions, and geographic locations (Davenport 1998; Kumar et al. 2002). This integration includes all the business functions of the enterprise, and included sophisticated reporting and optimizations. Furthermore, this integration and automation is facilitated by the inclusion of best practices to facilitate rapid decisionmaking, cost reduction, and greater managerial control (Holland and Light 1999). ERP systems consist of a suite of software modules, each responsible for a different business function. These modules can be purchased separately, or they can be combined together according to the needs of the firm. These modules include accounting management, financial management, workflow management, production management, project management, logistics management, inventory management, human resources management, supply chain management, customer relationship management and others. In a typical ERP, the modules would share and transfer information freely, thus an integration of functions of the firm would be realized (Chalmers 1999). Organizations have adopted ERP systems for several reasons. The most important reasons mentioned in the literature are integration capability, reputation, and standardized software. ERP systems streamline the data flows of organizations and provide management with a direct real-time access to a wealth of information (Davenport 1998). The ability to take advantage of real time information is cmcial for increasing productivity in organizations. Also, the replacement of ERP systems with legacy systems reduces the number of software programs and the needed support and maintenance. The high cost of in-house system building will also be reduced (Holland and Light 1999). On the other hand, such complex systems come with risks, both tangible an intangible. Especially, with the absence of tedious planning, the amount of risk may increase substantially. Since ERP systems may force a change in the business processes, it is important to know the business implications of ERP systems before implementation

Ework and ebusiness in architecture, engineering and construction

662

(Davenport 1998). Further-more, ERP implementations generally require more time, money, and effort to be installed (Holland and Light 1999), and the outcomes of the implementation may require years. In a recent study, it was estimated that customers spend between three and seven times more money on ERP implementation and associated services compared to the purchase of the software license (Scheer and Habermann 2000). 1.2 ERP solution for the construction industry The construction industry has a truly unique character. Although, it shares some similarities with manufacturing industry in terms of processes and disciplines, but it mostly produces customized one time order products. Some of these projects may last for years. Also, the construction industry operates project-based activities that are carried out by many different parties. All of these parties that constitute different organizational entities perceive the project with different goals. Furthermore, the construction industry has many problems, such as the fragmented and the inefficient nature, and the technology-averse practices. Most importantly, the construction industry has not been able to realize the information integration management fiilly, which could hinder productivity and quality. These issues have led the construction industry to look for new techniques and solutions to resolve these issues and to enhance its productivity (Zhang and Tiong 2003). The amount of information and its time-sensitiveness in the construction industry makes it very hard to be managed. Furthermore, several industry characteristics such as the large amount of different organizations participating in the project, lack of control on the project location and working conditions of construction sites, and fragmentation within the industry makes information management even harder (Russell andFroese 1997). While there are several standalone scheduling, estimating, cost control and accounting software, manual, paper-based information flow on construction projects is still very common (Shahid and Froese 1998). Many standalone computer applications are used in different departments, and the output of one, is reentered as an input by the other department of the firm. The industry lacks standardized systems that help integrate those tasks. Many firms have developed in-house systems for each department. These systems are generally point to point solutions and they are not integrated to other departments, or project sites. As a result, multiple entries of the same data occur between one application and another. Furthermore, there is a lack of interface with office applications. Another important issue is the lack of real-time information. Especially in a timeoriented business such as the construction industry, this issue causes many problems. Also, the absence of tools to act in advance and on-time foster a reactive management rather than a proactive management. Meanwhile, ERP systems offer real-time integrated information systems that can be a solution to the information integration problem of construction firms. Yet, generic standard ERP systems that are offered are not able to address the unique business needs of project-oriented organizations, including the construction industry. Extensive customization is required to be able answer these specific needs. This has been the primary reason for the low implementation rate of these systems in the construction industry.

Modeling of ERP system solutions for the construction industry

663

Figure 1. ERP with the construction site as the central element (adapted from SAP 2001). There are many diiferences in the business and accounting requirements of project-based firms. Some of these differences can be listed as follows: • Tracking costs and profitability on a project-by-project basis, • Providing timely project information to managers and customers, • Submitting accurate and detailed bills/invoices, often in compliance with complex industry-specific and regulatory requirements. In addition, there are many unique project-based processes that are not addressed specifically by standard ERP systems: job costing, managing the sub-contactor, financial reporting, managing the workforce, process time and expense, winning new business, purchasing goods and services, managing the project, and build to order. These differences have formed a gap between offered ERP solutions and the needs of the construction industry. Fortunately, the saturation of the market in other industries led ERP vendors to look at unexplored industries and to expand their existing services (Piturro 1999). As a result of this, major ERP vendors have tailored their software to fit the construction market. ERP tailored for the construction market is promising to solve the hindered integration problem. SAP, Oracle, and PeopleSoft are the largest ERP vendors that have already tailored their solution to fit the construction industry. In order to answer to the needs of the construction industry, an ERP should be based on the project site. This is illustrated in figure 1. Also, it should be compatible with the

Ework and ebusiness in architecture, engineering and construction

664

way construction firms are doing business. Industry specific processes and accounting standards should be designed comprehensively. Furthermore, there should be all the necessary interfaces with standard engineering, scheduling, and office software. Internet should also be utilized to access information worldwide. 1.3 Problem statement As mentioned earlier, ERP systems have had a huge impact on many industries, and mostly on the manufacturing industry. Yet, compared to other industries, these significant impacts have not been realized in the construction industry. Although some large construction companies have implemented certain modules of ERP, there are few companies that have integrated their project-based information systems and their enterprise information systems. Moreover, it is observed that there are barely any ERP implementations in the mid-market construction companies. The successful diffusion of ERP in the construction industry may have substantial benefits and solutions to integration problems in the industry. However, research regarding the implications of ERP in the construction industry is extremely limited. There is an urgent need to know if these integrated systems could be implemented in the industry or not. Empirical research is needed to identify the factors that affect the adoption of ERP in the construction industry. Also, there is a need to investigate the relationship between the extent of ERP implementation and the performance of the construction firm. By knowing which factors may lead to the adoption of ERP and their level of impact, the awareness of the possible outcomes of ERP adoption in the construction industry will be revealed. Because of the absence of such a study, the real compatibility and usability of ERP systems in the construction industry remains undisclosed. 2 RESEARCH OBJECTIVES The overall aim of this research is to conceptualize the role of ERP in the construction industry through a holistic perspective. More specifically, the research aims to study the factors that affect construction firms in adopting ERP and to explore the impact of the extent of ERP implementation on the organizational performance. Given the gaps in the related literature and the stated problem statement, these questions will be investigated: • What factors influence the decision of construction firms to adopt ERP? • Are the factors that affect the decision of ERP adoption different from the factors that affect the extent of ERP adoption? • What are the critical barriers to the diffusion of ERP in the construction industry? • How would the extent of ERP adoption affect the organizational performance? • How would ERP success be measured in the construction industry?

Modeling of ERP system solutions for the construction industry

665

2.1 Significance of this study The results of this research will facilitate to have a big picture of the ERP phenomenon in the construction industry. This is crucial since many ERP providers are trying to tailor their solutions to the construction industry, despite the lack of knowledge on the demand and inner motivations o the industry. Also, this research will unearth any hidden opportunities of ERP and what the construction firms lack that prevent them from adopting these systems. Moreover, this research will open new doors to research in construction management. 3 ERP ADOPTION MODEL IN THE CONSTRUCTION INDUSTRY Many researchers from different disciplines have done empirical studies in the field of innovation, focusing on either the individual or organizational level. Diffusion of innovations (DOI) theory has been used extensively by many IS researchers to explain the adoption and diffusion of information technologies. Rogers (1995) defines an innovation as an idea, practice, or object that is perceived as new by the unit of adoption. Since ERP can be considered as a technological innovation, the use of DOI theory as a reference discipline for empirical studies will be appropriate. In fact, Waarts et al. (2002), and Bradford and Florin (2003) and have utilized the DOI theory for ERP adoption. The proposed model is shown in figure 2. This model has been proposed based on past research in IS/IT innovation adoption and diffusion, ERP literature, and IS implementation. The model addresses two different objectives to study. It identifies the factors that are related to ERP adoption, and then, it examines the relationship between the extent of diffusion and the organizational performance. 3.1 Adoption & diffusion of ERP In this study, a firm is considered to be an adopter if it has one or more ERP modules installed. If the firm does not have an ERP, but is planning to have one in the next 3 years, then that firm would be considered an adopter, too. On the other hand, a firm would be considered a non-adopter if it does not have any plan to purchase any modules of ERP.

Ework and ebusiness in architecture, engineering and construction

666

Figure 2. ERP adoption model for the construction industry. There are two measures are used for ERP; the likelihood of ERP adoption and the extent of ERP adoption. These measures were adopted from Thong’s study of IS adoption (1999). The likelihood of ERP adoption was measured by asking the future plans of adoption of ERP. The second measure was operationalized by the number of modules installed. This measure demonstrates the extent to which ERP has been adopted. 3.2 Perceived innovation characteristics The influence of perceived innovations characteristics has been frequently studied in the literature. Over twenty five characteristics can be cited from the relevant studies. Six factors are included in this study. These are: Compatibility of ERP systems, advantages of ERP systems, complexity of ERP systems, trialibility of ERP systems, observability of ERP systems, and cost of ERP systems. Importantly, adopters can perceive the innovation characteristics diiferently. For this reason, we utilize the perceived characteristics instead of the primary characteristics which are the objective characteristics that do not vary across organizations (Moore and Benbasat 1991).

Modeling of ERP system solutions for the construction industry

667

3.3 Organizational characteristics Organizational characteristics look at the structure and processes of an organization that constrain or facilitate the adoption of innovations (Chau and Tam 1997). Many studies have shown strong evidence of the relationship between these characteristics and innovations (Tornatzky and Fleischer 1990). Since we are interested in the different characteristics of construction firms and in how they operate in the adoption context, more emphasis is given to these factors. Fourteen factors are included in this study, which are: Classification, specialty area, contract delivery method, prqject delivery method, centralization, formalization, integration, strategic planning, top management support, satisfaction with existing system, champion, risk, geographic dispersion, and IT infrastructure. 3.4 Environmental characteristics The environment can be defined as the surroundings that a firm conducts its business. This includes the relationship of the firm with the industry, the competitors, the suppliers, the government and other external entities. Two factors that have been studied and welldocumented in the literature are included in this study: Competitive pressure and market uncertainty. 3.5 Organizational performance The literature is replete with studies on the impact of ERP on the organizational performance. Five dimensions of organizational performance have been considered in this study to capture the benefits of ERP. These dimensions were studied thoroughly by Shang and Seddon (2002). The five-dimensional framework they have developed is built on large body of previous ERP research. These five dimensions are: Operational benefits, managerial benefits, strategic benefits, IT infrastructure benefits, and organizational benefits. 4 METHODOLOGY Due to the limited research, this exploratory study is hypothesizing that the factors proposed in the research model will make key contribution to the adoption of ERP for the construction industry. A survey will be used to test the proposed model with a sample size of 100 construction firms. The questionnaire aims to capture the information reflecting the perceptions and practice of the adopters and non-adopters of ERP and the influence of the factors. The method of delivery would be a web-based survey. The survey method is utilized to establish the parameters of the model and the relationship between the dependent and independent variables. It also serves as a means to verify the research model. The empirical analysis will be complemented by a case study approach, with the aim of verifying and enriching the results. A detailed examination of three firms will be

Ework and ebusiness in architecture, engineering and construction

668

realized through personal interviews with key decision-makers within the selected firms. The combined results of inductive and qualitative approach would formulate the ERP adoption model for the construction industry. 5 CONCLUSION AND FURTHER RESEARCH This study is expected to be beneficial both for the industry and for the academia. The results of this research will facilitate to have the big picture of the ERP phenomenon in the construction industry. This is crucial since many ERP providers are trying to tailor their solutions to the construction industry, despite the lack of knowledge on the demand and inner motivations o the industry. Also, this research will unearth any hidden opportunities of ERP and what the construction firms lack that prevent them from adopting these systems. No study has attempted to investigate the ERP phenomena in the construction industry with such comprehensiveness. With this research, many practitioners will be able to get guidance regarding the factors that affects the adoption of ERP. In addition, the effects of ERP on the organizational performance of the adopted firms might provide a good knowledge map regarding the outcomes of such an investment. REFERENCES Bradford, M. & Florin, J. 2003. Examining the role of innovation diffusion factors on the implementation success of enterprise resource planning systems. International Journal of Accounting Information Systems 4(3):205–225. Chalmers, R.E. 1999. Small manufacturers seek best ERP fit. Manufacturing Engineering 16(5):4– 24. Chau, P.Y.K. & Tam, K.Y. 1997. Factors affecting the adoption of open systems: An exploratory study. MIS Quarterly 21(1):1–24. Computer Economics 1999. Annual Information Systems and eBusiness Spending Study. Computer Economics. Carlsbad, CA. Davenport, T.H. 1998. Putting the enterprise into the enterprise system. Harvard Business Review 76(4):121–131. Duplaga, E.A. & Marzie, A. 2003. Implementing ERP in manufacturing. Information Systems Management 20(3):68–75. Hoffman, T. 1998. ERP: The next stage. Computerworld, http://www.computerworld.eom/news/l998/story/0,11280,32580,00.html.As viewed on 5/5/2004. Holland, C.P. & Light, B. 1999. A critical success factors model for ERP implementation. IEEE Software 16(3):30–36. Kumar, V, Maheshwari, B. & Kumar, U. 2002. Enterprise resource planning systems adoption process: a survey of Canadian organizations. International Journal of Production Research 40(3):509–523. Moore, G.C. & Benbasat, I. 1991. Development of an Instrument to Measure the Perceptions of Adopting an Information Technology Innovation. Information Systems Research 2(3):192–222. Piturro, M. 1999. How midsize companies are buying ERP. Journal of Accountancy 188(3):41–48. Rogers, E.M. 1995. Diffusion of Innovations. New York: Free Press.

Modeling of ERP system solutions for the construction industry

669

Russell, A.D. & Froese, T. 1997. Challenges and a vision dor computer-integrated management systems for mediumsized contractors. Canadian Journal of civil Engineering 24(2):180–190. SAP 2001. mySAP engineering and construction: contractors. SAP Solution Brief. Scheer, W. & Habermann, F. 2000. Making ERP a success. Communications of the ACM 43(4):57– 61. Shahid, S. & Froese, T. 1998. Project Management Information Control Systems. Canadian Journal of Civil Engineering 25(4):735–754. Shang, S. & Seddon, P.B. 2002. Assessing and managing the benefits of enterprise systems: the business manager’s perspective. Information Systems Journal 12(4):271–299. Thong, J.Y.L. 1999. An integrated model of information systems adoption in small businesses. Journal of Management Information Systems 15(4):187–214. Tornatzky, L.G. & Fleischer, M. 1990. The processes of technological innovation. Lexington, MA: Lexington Books. Waarts, E., van Everdingen, Y.M. & van Hillegersberg, J. 2002. The dynamics of factors affecting the adoption of innovation. The journal of product innovation management 19(6):412–423. Zhang, N. & Tiong, R. 2003. Integrated electronic commerce model for the construction industry. ASCE Journal of Construction Engineering and Management 129(5):578–585.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

Construction informatics themes in the framework 5 programme Ž.Turk University of Ljubljana, Ljubljana, Slovenia ABSTRACT: The paper presents the results of a survey on the current and future research and development themes in construction informatics. The survey was conducted in the fall of 2003 among the participants of the ICCI cluster project. It is based on the topic-map of construction informatics that structures the R&D themes into (1) core themes—mostly creating knowledge and (2) support themes. The support themes address the research needs, transfer, deployment and impact of research. Core research themes are related to processing activities and communication/coordination activities. It has been found out that the 5th framework projects made a breakthrough in the themes related to ebusiness and e-commerce. Collaboration, integration and data management was strongly represented but more work is needed. Future themes are expected to be knowledge management, intelligent software and intelligent interfaces. The projects were mainly involved with the requirements analysis and prototyping. The community realizes that in the future more effort should go into commercialized industry deployment and the study of the impacts of the technologies.

1 INTRODUCTION Innovation and advancement in information and communication technologies (ICT) is moving at a rapid pace. Many EU-funded projects using state-of the-art technologies have produced, tested and implemented advanced software solutions for the construction industry. In the wake of the 6th framework projects like ICCI (http://icci.vtt.fi/) and ROADCON (http://cic.vtt.fi/projects/roadcon/) were supposed to prepare the funding bodies as well as the researchers for new tasks in the coming years and the thinking on what we (construction informatics professionals) are, where we are headed and what kind of obstacles are on the road. Specifically the ROADCON project (Zarliet al., 2003) tracked the way forward; ICCI was more involved with analysing and harmonizing the current research. The objective of this document is quantify RTD technical advancements within the ICCI partner projects, (OSMOS—cic.vtt.fi/projects/osmos/, eConstruct— http://www.econstruct.org/, DIVERCITY— http://www.nicve.salford.ac.uk/divercity/index.html, ISTforCE— http://www.istforce.com/, eLegal—http://cic.vrt.fi/projects/elegal and GLOBEMEN—

Construction informatics themes in the framework 5 programme

671

http://cic.vtt.fi/projects/globemen) by technological themes that are targeted by these projects and ICT technologies that are relevant in the their context and of the construction industry. 2 METHODOLOGY The study is based on the results of the survey among the participants of the ICCI member projects. The design of the survey was based on the definition of a generic process model of research and development that is then used as a basis for the topic map of construction informatics. 2.1 Process model of R&D The generic process model of research and development (RDPM) is shown in Figure 1. Industry needs and general human curiosities generate problems and questions. The research process, done by academia and other researchers, using the knowledge from other disciplines and principles of scientific investigation, results in knowledge (as well as new questions). The knowledge is then used in (1) teaching, (2) development of technology and (3) development of standards, codes, best practices etc. Through these three main mechanisms this new knowledge reaches the industry and affects the day-today business processes.

Figure 1. Simplified IDEF0-ish process model of R&D (RDPM).

Ework and ebusiness in architecture, engineering and construction

672

2.2 Types of activities in the RDPM Kinds of efforts/works in the Figure 1 can be further structured according to the technology maturity levels. The kinds of efforts include: Related to the emerging stage of research: – roadmap creation, research strategy development. – research needs assessment. – problem definition, requirements analysis. Related to the research and problem solving: – research that furthered state-of-the-art in general – research that furthered state-of-the-art in AEC – application of computer science in AEC Related to the transfer and use of research results: – software prototyping and demonstrators – contribution to standards – contribution to education – contribution to best-practice Related to the deployment of research results: – commercialized industry deployment Related to the impact of the deployed research results: – studies of economic/business impacts – studies of environmental impacts – studies of social impacts This classification was used in questions 3.2 and 4.2 of the Survey. 2.3 Construction informatics themes Construction informatics is an interdisciplinary topic that studies (the construction specific issues) related to representation, processing, and communication of (construction specific) information in humans and software (Turk, 2002). In the paper (Turk, ibid.) presented the topic map of construction informatics. It includes dozens of hierarchically structured topics. The hierarchy was found too much complex and hard to understand by the test respondents, therefore a linear list of well-understood topics was suggested. It was a design goal of these topics to omit the technical terms tied to a particular fashionable technology in order to make the form as time-proof as possible. The list of themes was: – collaboration, concurrent engineering infrastructures, project webs… – person-person communication technologies, videoconferencing, email… – software interoperability and integration, XML, IFC, STEP

Construction informatics themes in the framework 5 programme

673

– human-computer interaction – computationally intensive applications (FEM etc.) – knowledge intensive applications, AI, expert systems – knowledge management – 3D modelling and drafting – databases, information retrieval – business process reengineering – e-business infrastructures – e-legal infrastructures The list is further elaborated in Section 3. 2.4 The survey As a general method on getting the empirical data on the current an future research and problems that may lie ahead, a survey among the project partners of the ICCI member projects as well as the general research community was conducted in October and November 2003. Had five sets of questions: – General information about the project in which the respondent took part – Questions about the person responding – Theme and contribution of the project – Future research plans – Barriers and risks This paper focuses on the results related to the 3rd and 4th set of questions. Another paper (Turk, 2004) focuses on the barriers and risks. 2.5 Member projects The Figure 2 shows the projects there were studied. Most answers in the survey were related to the ICCI member projects, however, some also came from other parties. 2.6 General demographics of the respondents The survey was taken by 50 persons. The average age was 42 years. The average size of the company was 2600 employees, the median size 500. They spent 17.1 PM on average on the project on which they are responding. The business and work profiles of the respondents are shown in Figure 3.

Ework and ebusiness in architecture, engineering and construction

674

Figure 2. Projects studied and how they were represented in the survey.

Figure 3. Respondents of the survey.

3 CURRENT AND FUTURE EFFORTS Sections 3 and 4 of the questionnaire were dealing with topics and kinds of efforts in the current 5th framework research projects (Section 3) as well as in the planed future research projects (Section 4). This section discusses some overall results:

Construction informatics themes in the framework 5 programme

675

Current kinds of work Question 1.3 was dealing with the type of work that the person was doing in the project: – 42.3% research, development, demonstration, testing – 19.6% deliverables editing (writing project deliverables) – 15.2% dissemination efforts (writing papers, presentations) – 7.4% other paperwork for the EU – 14.2% proj ect management – 4.5%other

Figure 4. Themes of the current (above) and future (below) themes of the research projects. Over 1/5 is spent of what could be described as project management (the limit for this kind of funding in the 6th Framework is 7%!). What also seems wrong is the difference in the effort related to deliverables editing and dissemination. The first is typically very low circulation reports often read by the consortium, project officer and reviewers only, the second are publications in journals, trade magazines, at conferences and fairs—for a much wider audience and often subject to peer review.

Ework and ebusiness in architecture, engineering and construction

676

3.1 Current and future themes Current research themes are shown in Figure 4. Several figures like this will be printed in this report. With each row, the respondents could answer not just with yes/no but with answers between 1 and 5. The proportion of each answer is color coded in the Figures. Red bar stands for 5, orange for 4, yellow for 3, vanilla for 2 and grey for 1. “Darker” bar therefore means more. It should be noted first that the respondents were critical of their current and optimistic about their future contribution. On average, the contribution of the future project would be more than half a grade “more significant” than the current project. Tables 1 and 2 show the current and future research themes. On the left there is the ranking of themes in the current projects. Higher numbers in front of the theme mean stronger contribution. It is the average of all answers. The right hand side is based on the answers to 4.1 and shows the themes of the future projects.

Table 1. Current and future research themes. Movers up in bold, movers down in italic. Rank Current (question 3.1)

Change Rank Future (question 4.1)

1

3.9 collaboration, concurrent engineering infrastructures, project webs…

0

1 4.0 collaboration, concurrent engineering infrastructures, project webs…

2

3.2 software interoperability and integration, XML, IFC, STEP

4

2 3.8 knowledge management

3

2.9 e-business infrastructures

4

2.9 databases, information retrieval

0

4 3.3 databases, information retrieval

5

2.7 business process reengineering

2

5 3.2 knowledge intensive applications, AI, expert systems

6

2.6 knowledge management

2

6 3.2 human-computer interaction

7

2.3 knowledge intensive applications, AI, expert systems

−4

7 3.2 e-business infrastructures

8

2.3 human-computer interaction

−3

8 3.2 business process reengineering

9

2.2 person-person communication technologies, videoconferencing, email…

10

2.0 3D modelling and drafting

11

1.9 e-legal infrastructures

0

11 2.4 e-legal infrastructures

12

1.4 computationally intensive applications (FEM etc.)

0

12 1.9 computationally intensive applications (FEM etc.)

−1

1

−1

3 3.7 software interoperability and integration, XML, IFC, STEP

9 2.8 3D modelling and drafting

10 2.6 person-person communication technologies, videoconferencing, email…

Construction informatics themes in the framework 5 programme

677

Table 2. Changes in the cureent and future kinds of efforts. Rank Current

Change Rank Future

1

3.8 software prototyping and demonstrators

0

1 4.1 software prototyping and demonstrators

2

3.5 problem definition, requirements analysis

0

2 3.8 problem definition, requirements analysis

3

3.5 application of computer science in AEC

3

3 3.8 contribution to best-practise

4

3.4 research that furthered state-ofthe-art in AEC

4

4 3.8 commercialized industry deployment

5

3.3 research that furthered state-ofthe-art in general

4

5 3.7 studies of economic/business impacts

6

3.3 contribution to best-practise

−1

6 3.7 research that furthered state-ofthe-art in general

7

3.0 contribution to standards

−3

7 3.5 research that furthered state-ofthe-art in AEC

8

3.0 commercialized industry deployment

−5

8 3.5 application of computer science in AEC

9

2.9 studies of economic/business impacts

−2

9 3.4 contribution to standards

10

2.6 research needs assessment

1

10 3.2 contribution to education

11

2.6 contribution to education

1

11 3.1 roadmap creation, research strategies

12

2.3 roadmap creation, research strategies

−2

12 3.0 research needs assessment

13

2.0 studies of social impacts

0

13 2.7 studies of social impacts

14

1.9 studies of environmental impacts

0

14 2.6 studies of environmental impacts

Top themes like “collaboration, concurrent engineering infrastructures, project webs…”, “software interoperability and integration” and “databases, information retrieval” will remain in the focus of the research of this community. e-Business related themes seem to have addressed all relevant issues and are loosing priority in the future. The overall winner (green background) are themes related to knowledge management and humancomputer interaction. The “losers” are e-business related themes.

Ework and ebusiness in architecture, engineering and construction

678

3.2 Current and future “kinds of efforts” The Figure 5 compares the current and future kinds of efforts. Again the future efforts are stronger than the current ones (1/4 of a point).

Figure 5. Current and future “kinds of efforts”.

Construction informatics themes in the framework 5 programme

679

The changes are perhaps better understood from Table 2. It is quite apparent that the respondents feel a need for a stronger transfer towards the practice, commercialization and the study of the economic and business impacts (text in bold). On the other hand, pure research and application of computer science to AEC is loosing the attention (text in italic). 4 SELECTED ICT TOPICS AND DISCUSSION OF THEIR REPRESENTATION IN THE SURVEY This section details the themes of RTD projects, both current and future and presents some results related to those themes, from the survey. Each topic is briefly introduced. Then, based on the survey, four facets are discussed: Status: how was the topic represented in the current research (question 3.1) Trend: how is the topic represented in the future research (question 4.1) Future themes: what topics will in the future (question 4.1) study the persons, who thought that their current project did an above average contribution (question 3.1) in this topic Barriers: what barriers were found most severe by persons who did an above average contribution in this theme? 4.1 Collaboration, concurrent engineering infrastructures, project webs…(common infrastructures—collaboration) Infrastructure to enable the movement and communication of information over networks (e.g. The Internet, the Web, portal and communication infrastructures). Status: strong Trend: up-stable Future themes: more of the same, knowledge management Barriers: funding, business case, demonstrators don’t scale up. 4.2 Person-person communication technologies, videoconferencing, email… (communication person-person) Communication of information between individuals to support coordination and collaboration in human activities and work processes in the construction business. Software and technologies serving this function can support distance working, virtual workspaces, concurrent engineering and the virtual enterprise. Software like email, chat, ICQ, on-line conference, project webs, groupware and workflow tools and technologies like Internet technologies, Web technologies, Mobile technologies, Workflow technologies. Status: weak Trend: up-stable Future themes: collaboration, e-business infrastructures Barriers: fixation to old problems, enlightened managers missing.

Ework and ebusiness in architecture, engineering and construction

680

4.3 Software interoperability and integration, XML, IFC, STEP (communication software-software) Software, programs and technologies that enable automated machine-to-machine communication, distribution and sharing of software and computing resources, data exchange and data transfer. Software like SMTP, FTP, server and middleware technologies like CORBA, DCOM, SOAP and GRID technologies, inter-process communication like COM and protocols like HTTP, XML. Status: strong Trend: up-stable Future themes: more of the same, knowledge management Barriers: fixation to old problems, funding, success failure, demonstrators don’t scale up. 4.4 Human-computer interaction (communication person-software) The interface between a user and a software program or a display device that defines how the user interacts with the software or device and views information presented e.g. how software controls and information fields are laid out and organised in screens, windows and forms, visualisation of information and entering of data. Software, tools and technologies for user interfaces and interactive devices e.g. mouse, touch screens and visualisation of information like virtual reality environments. Status: weak Trend: up Future themes: collaboration, HCI, more of the same, knowledge management Barriers: community closed for new ideas. 4.5 Computationally intensive applications (FEM etc.) (processing— create information) Support for human activities in creating, analyzing and processing information by using software and programs. Synthesis like drafting, computer aided design (CAD) and 3D modelling, analyzing like design, structural design, structural analysis, finite element analysis and data processing to create new information like machine learning and regulation checking. Status: very weak Trend: will continue to be weak Future themes: more of the same, several other topics. Collaboration significantly not an issue! Barriers: comparably few, funding not seen as a problem. 4.6 Knowledge intensive applications, AI, expert systems This is the other topic that actually creates new information, this time by using knowledge and logic intensive applications, not computationally intensive. Includes technologies such as data mining, expert systems and other artificial intelligence tools (AI).

Construction informatics themes in the framework 5 programme

681

Status: average-strong Trend: up-stable Future themes: knowledge management, more of the same, interoperability, HCI. Collaboration not a future issue! Barriers: stakeholders not involved, educators, software developers, standardisation bodies not involved in the project team, does not address user needs, funding. 4.7 Knowledge management Knowledge management involves the identification and analysis of available and required knowledge assets and knowledge asset related processes, and the subsequent planning and control of actions to develop both the assets and the processes so as to fulfil organisational objectives. Status: average Trend: up Future themes: more of the same, databases, information retrieval, business process reengineering, e-business infrastructures… Barriers: funding, old problems not solved. 4.8 3D modelling and drafting (processing—create information) In themes 4.5–4.7 new information is created by software. However, in the AEC, a substantial body of information is created by the designers by drafting (2D) and modelling (3D). Status: average—low Trend: down Future themes: more of the same, collaboration, knowledge management. Not interested in e-business infrastructures. Barriers: old problems not solved, demonstrators do not scale up, enlightened managers missing. 4.9 Databases, information retrieval (processing—manage information) Support for human activities in managing collections of data and information, in the construction business, over its life cycle. Manage information includes the representation and structuring of the physical information (e.g. format, schema, ontology, data structure, XML), modelling it (e.g. business information modelling, enterprise modelling, product modelling, STEP, IFC, process modelling, IDEF0), software and technologies for physically storing and organising it (e.g. relational and OO databases, product model databases, data warehouses, knowledge management, document management) and retrieval and search technologies and mechanisms (e.g. data mining, search, query, classification, thesaurus, vocabulary, glossary). Status: above average Trend: slightly down Future themes: more of the same, collaboration, knowledge management. Not interested in e-business infrastructures.

Ework and ebusiness in architecture, engineering and construction

682

Barriers: old problems not solved, clear business case with ROI study missing, demonstrator does not scale up, industrial robustness not achieved, difficult to use. 4.10 Business process reengineering The study of how technological advances translate into new ways of organizing and doing business. Status: average Trend: slightly up Future themes: collaboration, knowledge management, e-business infrastructures Barriers: funding, community closed for new ideas, enlightened managers missing. 4.11 E-business infrastructures (common infrastructures—commerce) Infrastructure to support and facilitate, the business process, in delivery, buying and selling of products and services, sales support and communicating information to business partners in business and commerce and by means of electronic transactions (e.g. e-Business, e-Commerce and e-Procurement systems). Status: above average Trend: down Future themes: collaboration, interoperability, HCI Barriers: clear business case with ROI study missing, demonstrator does not scale up. 4.12 E-legal infrastructures (common infrastructures—legal) Creating, owning and distributing electronic information is of legal consequence. Methods, technologies legal standards, laws and regulations designed to protect information owners, information users, legal documents and contracts, intellectual property rights, authentication of information and safe transport of information over the global network (e.g. digital signatures, digital encryption, digital contracts etc.). Status: low Trend: will stay low Future themes: collaboration, more of the same, integration, e-business infrastructures. Barriers: demonstrator does not scale up, industrial robustness not achieved, difficult to use, old problems not solved. 5 CONCLUSIONS The survey is providing an interesting insight into the RTD advances and migration risks. The 5th frame-work projects seem to have made a decisive/sufficient breakthrough in the themes related to e-business and e-commerce (which were, to be fair, quite popular at the time). In spite of the large proportion of the efforts that was related to collaboration, integration and data management, further work in this area is likely. Among the new

Construction informatics themes in the framework 5 programme

683

themes identified are those related with the knowledge management, intelligent software and intelligent interfaces. Major effort of the projects was in the requirements analysis and prototyping. In the future, more eifort is expect related to commercialized industry deployment and the study of the impacts of the technologies. ACKNOWLEDGEMENT The work reported was conducted in the context of the IST-ICCI Project. The financial support of the European Commission under the IST program as well as the contribution and comments of the ICCI partners, particularly Gudni Gudnasson, Vlado Stankovski, Tomo Cerovšek and Matevž Dolenc is acknowledged. REFERENCES Rezgui, Y. & Zarli, A. 2003. ROADcon: a European strategic roadmap towards knowledge-driven “sustainable” Construction, Civil Engineering Journal, October. Turk ž 2002. Elements of an Ontology of Construction Informatics, In Y.Rezgui B.Ingirige G.Aouad (eds), Proceedings of the European Conference on Information and Communication technology Advances and Inovation in the Knowledge Society—eSMART 2002, University of Salford, ISBN 0902896415, 155–167, http://www.zturk.com/. Turk ž 2004. Migration Risks of Construction Informatics Research, position paper in D.J.Vanier and T.El-Diraby, Integrated IT to support Sustainable Construction”, Toronto, Canada, May, 2004, http://www.zturk.com/.

Ework and ebusiness in architecture, engineering and construction

684

Collaborative working

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 9384

Virtual pools of resources eliminate idle or missing equipment in AEC companies G.Antoniadis Intracom S.A., Hellenic Telecommunications & Electronic Industry, Greece K.Menzel Dresden University of Technology, Germany ABSTRACT: Best utilization of the productive resources is a vital need for construction companies. The “e-Sharing” project (Resource Sharing Constellations—IST-2001–33325) introduces an innovative service for the efficient management of resources by enabling resource sharing within different companies. e-Sharing, supports resource type models based on XML schemas, employs intelligent functionality for matching offers and requests and provides advanced auctioning and negotiation procedures by using software agents. The e-Sharing has been designed on the principle to be a practical and useful tool for professionals who need realistic and integrated solutions for their work. This paper, in addition to the presentation of the system individual functionalities, demonstrates the strength of the approach and the benefits that e-Sharing offers to lessors, lessees and service providers.

1 INTRODUCTION Best utilization of the productive resources is a vital need for construction companies. While any unpredicted need in important resources may result in difficulty in fulfilling a contract or in loosing a business opportunity, a temporary and unexpected business decline may result in having idle resources. Construction companies really need a fast and dynamic way of acquiring specific resources to cope with work peaks and a way of exploiting their idle resources and compensating for their fixed expenses. The modern technology that offers high capabilities in interconnecting systems and users, fast and intelligent information searching and advanced electronic bargaining methods, make the concept of a virtual shared pool of idle resources, feasible. The e-Sharing system is based on powerful resource and task type models, which further extend existing standards in Construction Equipment and Tasks. e-Sharing combines them with each other and provides a formal specifications in an XML schema dialect. Sharing of resources is achieved by the introduction of a virtual resource pool that includes the company-user’s own available resources and the idle resources that have been declared in the “e-Sharing” system by other company-users. To facilitate the data flow towards the pool of idle resources, e-Sharing allows data extracted from the users

Virtual pools of resources eliminate idle or missing equipment in AEC companies

687

ERP systems to be loaded to the system by means of XML messages and a web connection. Data Mining technology is used for analysing data from offers and requests. The users of the e-Sharing system describe their requirements regarding resource special characteristic, leasing period and price and the intelligent recommendations engine of the e-Sharing system presents all the available solutions in a list with the most suitable resources in the first positions. Estimated initial values auctions and negotiations are also specified. Various types of electronic auctions, various types of electronic negotiations and various types of bidding agents that can participate in the electronic bargain on behalf of the users, give a sample of the trading facilities that accompany the system and can be used for achieving fast and profitable deals between the owners of the resources and the potential lessees. The various characteristics of the e-Sharing system are presented in the next sections as follows: Section 2 presents the resource description models, section 3 presents the matching and recommendation mechanism, section 4 presents the e-sharing Trader, while the strength of the approach and the users benefits are discussed in sections 5 and 6 respectively. We conclude in section 6. 2 RESOURCE DESCRIPTIONS A prerequisite for the spreading of the e-Sharing service is the existence of strong resource and tasks description models. The models’ compatibility to the users practices, their completeness, extensibility, and broad acceptance from the construction industry, is the key factor for pulling together users so that a resource sharing community is formed. The basis for the development of the integrated resource model in the e-Sharing project was an analysis of existing standards and catalogues describing construction equipments, construction tasks, and qualification profiles to select the most detailed and general content descriptions and the appropriate models. The analysis was divided into two sub-tasks: Firstly, content information for equipments and tasks as well as qualification profiles in the construction sector was analysed. In a second step the content specification was compared to existing standardized schemata in order to define the appropriate schema to manage and maintain resource information. The evaluation process was conducted in close cooperation with industry partners and further potential end-users of the e-Sharing sy stem to continuously consider their requirements and experiences [Menzel, 2004]. 2.1 Equipment types The BGL 2001 [BauGeräteListe, 2001] specifies technical and relevant financial information about equipment types in the construction sector. The BGL 2001 is used for the estimation of costs as well as technical performances of construction equipment. Each equipment type is specified by characteristic technical properties like height, load moment or velocity. Based on the BGL 2001 the so called EUROLISTE has been developed in cooperation of French and German authorities. The aim of the EUROLISTE

Ework and ebusiness in architecture, engineering and construction

688

is to harmonize standards for construction equipment in Europe. EUROLISTE/BGL 2001 is the most complete and most detailed content description of equipment types in the construction sector. Therefore, we have chosen the EUROLISTE/BGL 2001 as content description. 2.2 Construction tasks For construction projects in Germany the STLB [StandardLeistungsBuch 2004] categorises construction tasks in a hierarchical order. Furthermore, each task can be specified by certain properties which describe the type the amount of work that has to be performed. Currently, the STLB is the most complete and most detailed content description of task types in the European construction sector. Therefore, the STLB was chosen in e-Sharing as content description for construction tasks. 2.3 bc-XML: A schema for equipment and tasks In order to determine the appropriate schema that can describe equipment types and task types for the e-Sharing system, two different criteria have been identified: Firstly, information of equipments and tasks has to be structured hierarchically while attaching certain properties to them. Thus, inheritance of properties must be supported. Secondly, in order to find the appropriate equipment for a certain task equipment types and task types must be comparable. Consequently, the two models shall be compatible. These requirements are sufficiently covered by the bc-XML (developed within the “eConstruct” project (http://www.econstruct.org/) specification, which can be used for both, the equipment type description and the task type description. 2.4 Qualification profiles of personnel in AEC Under the guidance of the British Department of Education and Employment (DfEE) the Construction Industry Standing Conference (CISC) [http://www.cisc.org.uk/] developed a framework for National Vocational Qualifications (NVQ) [http://www.uce.ac.uk/], and Scottish Vocational Qualifications (SVQ). The first version was delivered in 1994. Within e-Sharing the descriptions of “level 4” and “level 5” qualifications for the construction sector will be used. Under the guidance of the German Assembly of the “Chambers of Handicrafts” app. 50 job descriptions are maintained as standardised qualification profiles (comparable to “level 1” to “level 3” of the NVQ’s). The CISC-approach and the job descriptions complement each other. This holistic approach ensures the usability of our approach to different organization types within the construction sector. 2.5 HR-XML—A Schema for qualification proflle representation Within the e-Sharing project human resources (HR) are characterised through knowledge and skills of a person (like a certificate for crane operation or a welding certificates). Therefore, the schema describing the qualification profiles has to fulfil two requirements: Firstly, it should be a neutral standard in order to allow integration of information from

Virtual pools of resources eliminate idle or missing equipment in AEC companies

689

external systems, and secondly, the content for skills and knowledge (as described above) has to be represented in the schema. The HR-XML [http://www.hr-xml.org/] specification supports these requirements to the best. 2.6 ERP data transfer The XML representation of the resources allows for simple communication berween eSharing and the customers ERP systems. Lists of idle resource extracted from the companies ERPs, are coded to

Table 1. Content and Schemas Description in construction. Category

Models & Schemas

Content descriptions

Equipment

bcXML

BGL-2001

Task

bcXML

STLB

Qualification profiles

HR-XML

CISCAEC-Qual.Prof.

XML messages containing the resource descriptions. XML messages are send to eSharing by agents that reside on computers of companies-users. The incoming XML messages are processed in e-Sharing by an XML-Parser and are inserted into e-Sharing database. 3 INTELLIGENT RECOMMENDATIONS ENGINE The e-Sharing intelligent recommendations engine, detects all the offers that could be interesting for a specific lessee’s request, and evaluates them on the basis of the probability of a successful negotiation between the lessor and the lessee. In e-Sharing when a user registers a new offer or request for a resource, he has to specify the following parameters: (1) Resource type & specific characteristics, (2) Leasing period, (3) Price For each parameter, the users have also to specify how flexible they are on accepting different values by selecting one out of three different values of a flexibility indicator: (a) high flexibility (b) medium flexibility (c) low flexibility [Morris, 2000]. Based on the specified parameters value, and the flexibility indicator (high, medium, low), for each parameter the system estimates automatically the flexibility factor for each parameter. The flexibility factor is the system estimation of the percentage of the increase or the decrease of the specified parameter value, which would be accepted by the user. The flexibility factor takes a different value for each transaction and depends on the specified value for this parameter and the values and the flexibility indicators for the other parameters of a transaction (e.g. the flexibility factor for price depends on the resource type, on the period of the year, on the leasing interval, etc). The system estimates the flexibility factors by mining the data of all previous transactions [Han, 2001, Michlski, 1998].

Ework and ebusiness in architecture, engineering and construction

690

e-Sharing employs a data mining classification procedure in order to obtain distinct values such as 5%, 10%,…95%, 100%, for the flexibility factors for the parameters price and time. Transactions historical data are transformed and stored in the Data Warehouse table. Fields in the Data Warehouse table store data about average transaction prices for that resource type, Request/Offer prices per resource type and period of the year, Requests/Offers density per time period etc. As only the price and time parameters can be negotiated by e-Sharing, only the flexibility factors for these parameters are calculated by data mining. The data in the Data Warehouse are mined by a batch procedure once a week in order a Decision tree to be formed for each flexibility factor. The resulted Classification Models are used in order to predict the flexibility factors for new requests or offers [Oracle 9i, 2002]. Taking into consideration all parameters i in an offer and request pair and their flexibility factors, each offer-request pair is rated by the sum: Σ ((iR·(1+fiR)−io·(1−fio)) (for all params i) Where: iR, fiR, are the value and flexibility for parameter i in a Request; iO, fiO are the value and flexibility for parameter i in an Offer. Sorting the rates for each Offer-Request pair, creates the system recommendation. First item in the recommendation list is the item with minimum value for the above expression. 4 THE TRADER The constructions sector is characterized by high investment cost of certain equipment and difficulty in maintaining a higher usage level of this equipment. These features leave a wide space for benefits to both lessors (by earning revenue from idle equipment) and lessees (lower investment requirements). The e-Sharing Trader’s goal is to increase the overall market efficiency by supporting trading mechanisms for fast, transparent and efficient sharing of resources by means of electronic auctions and negotiations [Bitsaki, 2004]. 4.1 Auctions The auction-related part of the Trader supports a variety of popular auction mechanisms, both simple and multi-object, as opposed to most existing e-marketplaces. The selection and adaptation of these mechanisms are strongly motivated from the project’s context. Since market demand for specific types of equipment (e.g. cranes, excavators, trucks) is unpredictable due to the construction companies time-varying needs, it is very hard for lessors to set a fixed price for their resources. To this end, auctions seem to be the proper means of trade. The following auction types are supported by e-Sharing [Coucoubetis C., 2003]. First Price Sealed-bid auction: each bidder submits a sealed bid without knowing others’ bids. The object is awarded to the highest bidder. The winner pays his own bid.

Virtual pools of resources eliminate idle or missing equipment in AEC companies

691

Second Price Sealed-bid (Vickrey) auction: each bidder submits a sealed bid without knowing others’ bids. The object is awarded to the highest bidder. However, contrary to the first price sealed-bid auction, the winner pays the second-highest bid. English auction: it is an open process, with price ascending progressively. In particular, the price starts from the lowest acceptable level and proceeds to solicit higher bids from the bidders until no one is willing to increase the bid. The object is awarded to the highest bidder, who pays his bid. Multi-object Auctions. When multiple identical items or multiple units of a divisible quantity are to be traded, the respective mechanisms are defined as multi-unit auction mechanisms. Sealed bid multi-object auction: bids are submitted in sealed envelopes. The K units available axe allocated to the K highest bids. Ascending clock auction: this is a progressive auction mechanism; hence it is conducted in rounds. A clock indicates the current per unit price, and bidders report the quantity demanded for this price; the clock price is then raised again. Bidders gradually reduce their demand (they are not allowed to increase it) and units are awarded to bidders when demand matches supply. Combinatorial sealed-bid auction for 2–3 objects: bidders are allowed to submit any combination of units they wish at a single price. Examining all possible overall allocations and finding the most profitable one perform winner determination. 4.2 Agents in auctions e-Sharing enables users to select among various types of bidding agents to participate in the English type auction on their behalf. Users’ presence in the system is not necessary during the auction any more. The agents developed by e-Sharing are based on input of certain parameters given by the user. They pertain to auctions taking place for a predefined time period. In particular, three types of agents have been defined and implemented. The “Simple Agent”, which increases the bid up to the user’s maximum willingnessto-pay without taking any special care if the auction is nearing its completion. The “Smart Agent”, which increases the bid by a small increment until he realizes that the auction is nearing its completion. It then places one last bid, which is computed according to a formula giving the optimal such bid under certain assumptions. The “Adaptive Agent”, which is applicable when the user’s willingness-to-pay is not accurately known, or can be influenced by the bids of the other players/ agents. 4.3 Negotiations The e-Sharing Trader supports negotiations among users by means of a semi-structured negotiation protocol. Inclusion of this functionality is primarily motivated by the fact that in the construction sector, negotiations are very common. This implies that the Traders’ users are familiar eith the basic principles of negotiations. Moreover, researcher’s studies [Bichler, 2003] also agree that electronic negotiations are very promising. The users negotiate by exchanging messages of standardized structure and content eliminating misunderstandings and save time and money for the parties involved. This should be

Ework and ebusiness in architecture, engineering and construction

692

contrasted with traditional negotiations that are conducted either face-to-face or by using the telephone, or simplified electronic negotiations that are conducted by means of exchanging unstructured details. The latter type of negotiations suffer from high transaction costs and limited number of negotiation parties since negotiations among a lessee and many lessors for the leasing of a resource is impossible over the phone. Electronic negotiations can only be effective if resource description and negotiation objects’ structure are standardized. Project e-Sharing has performed innovative work on accurate resource description and related ontology. This motivates the use of automated price negotiation agents that exchange negotiation messages on users’ behalf. The following types of negotiations are supported by e-Sharing. Multi-attribute negotiations; The users negotiate for multiple parameter e.g. the price and the leasing period. Two-object negotiations, AND-type negotiation: this feature allows a lessee to lease two complementary resources that are offered by generally different lessors or none of them, e.g. both an excavator and a truck that are needed for a construction project. Two-object negotiations, OR-type negotiation. Negotiation for exactly one of two substitute resources, e.g. one of two cranes that are offered by two different lessors (ORtype negotiation). The support of this functionality is strongly motivated from the needs of the constructions sector, where the existence of such complementarities or substitutions among resources is common. 4.4 Agents in negotiation The e-Sharing Trader provides a family of negotiation agents, each reflecting different behavior regarding the urgency to make a deal and the risk aversion degree. Impatient agents that approach (or even reach) their reservation value very quickly. Patient agents that reveal their reservation value when time is almost exhausted. Regular agents that approach steadily the reservation value until time is exhausted. STRENGTH OF THE APPROACH 5 The strengths of the approach, which make it appealing for exploitation are the following: • in the particular sector of construction, the high investment cost of certain equipment and the difficulty to maintain a large usage rate of this equipment, leave a large space for benefits to both lessors (income from idle equipment) and lessees (less investment requirements). • e-Sharing explores new approaches to flexible work forms that will allow enterprises to be more competitive in an increasingly global business environment and at the same time to keep their employees, increase the work stability and reduce the unemployment. Compliance with EU efforts in employment is worth noting. • the owner of e-Sharing business is only a mediator and does not have to invest in purchasing the resources to be leased. The value of the leasing transactions is large enough to allow a descent revenue to the mediation service provider.

Virtual pools of resources eliminate idle or missing equipment in AEC companies

693

The main effort in developing the e-Sharing platform is in shaping the applications according to the special needs of the resource sharing scenario. Additionally, effort is targeted to the development of special components with advanced characteristics such as sharing-specific matching agents and intelligent recommendations. A number of these components, triggered original R&D work, including an advancement in the corresponding research. The compilation of characteristics tailored to real workscenarios provides e-Sharing with a competitive advantage. The e-Sharing approach will contribute to new ways of working by supporting easy co-operation of SMEs in the construction sector. It contributes to easier establishment of new organizational patterns, such as Virtual Organizations (VOs), and therefore strengthens and extends the competitiveness of SMEs and the construction sector in general. Especially in the very fragmented and specialized construction sector this will lead to productivity gains. Moreover, the e-Sharing approach enables access to modern and up-to-date construction equipment on a cost-effective basis. By leasing high-tech construction equipment SMEs can immediately improve their market position without having the need for heavy investment. 6 BENEFITS OF THE E-SHARING SYSTEM The e-Sharing system has been designed on the principle to be a practical and useful tool for professionals which provides a quick and reliable way for seeking or exploiting resources and a great flexibility in transactions between users. The benefits for all the involved parts are significant: • Lessors (Equipment owners) – Exploitation of idle resources – Targeting of the offered resources to a special and attentive audience – Fast agreement completion – Profitable deals by means of advanced auctioning and negotiations features. • Lessees (Companies undergoing resource shortages) – Constantly available resources to select – Many alternative types of resources to select – Combinations of resources to accomplish a task – Access to rare resources – Fast seeking of the most suitable resources – Profitable deals by means of advanced auctioning and negotiations features. • Service provider – Marketplace domination by unifying highly fragmented markets – International market penetration by exploiting the system’s multilingual capabilities – System extensibility to other business environments by including new resource categories – Big profit possibilities by maintaining a continuous stream of transactions.

Ework and ebusiness in architecture, engineering and construction

694

7 CONCLUSION e-Sharing system presents a pioneering service which allows companies that undergo resource shortages to lease equipment or services form companies with temporarily vacant equipment or personnel. e-Sharing supports resource type models based on XML Schemas, employs intelligent functionality for matching offers and requests, and provides advanced auctioning and negotiation procedures by using software agents. e-Sharing can cooperate with the individual company’s ERP systems, providing a fast and dynamic Resource Management tool. REFERENCES BauGeräteListe 2001, German National List of Construction Equipment Bichler M., Kersten G., Stecjer S., 2003, Towards a structured Design of Electronic Negotiations. Group Decision and Negotiation, Vol. 12, No. 4 (311–335). Bitsaki M., Dramitinos M., Stamoulis G., Antoniadis G., 2004, An e-Marketplace for Auctions and Negotiations in the Constructions Sector, On The Move to Meaningful Internet Systems and Ubiquitous Computing, CoopIS 2004, Larnaca Cyprus Courcoubetis C., Weber R., 2003, Pricing Communication Networks: Economics, Technology and Modelling, John Willey & Sons Han J., Kamber M, 2001, Data mining: Concepts and Techniques, Morgan Kaufmann Publishers Menzel K., Wagner U, Keller M., Antoniadis G., Caires Branco A., 2004, Resource Management for the Construction Industry, Xth International Conference on Computing in Civil and Building Engineering. Weimar, Germany Michlski R., Brakto L, Kubat M., 1998, Machine Learning and Data Mining: Methods and Applications., NY: John Wiley & Sons. Morris J., Maes. P, 2000, Negotiating Beyond the Bid Price. Workshop Proceedings of the Conference on Human Factors in Computing Systems (CHI 2000), The Hague, The Netherlands. Oracle9i Data Mining, 2002, Concepts. Release 2 (9.2) Oracle9i Data Mining, 2002, Administrator’s Guide. Release 2 (9.2) StandardLeistungsBuch 2004—Book of Standardised Construction Service Description http://www.cisc.org.uk/ http://www.hr-xml.org/

http://www.uce.ac.uk/

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

DIVERCITY: distributed virtual workspace for enhancing communication and collaboration within the construction industry Y.Arayici & G.Aouad School of Construction and Property Management, University of Salford, Greater Manchester, UK ABSTRACT: DIVERCITY is a large EU funded project in the area of construction IT undertaken by a European consortium of researchers and practitioners from the construction industry. It is the acronym for Distributed Virtual Workspace for enhancing Communication within the Construction Industry and the prototype that presents the mechanism to smoothly and collaboratively conduct the construction projects from early briefing to the detailed design and even further by the end of the construction phase. To be precise, DIVERCITY aims to supply a shared virtual construction design and briefing environment that enables the construction industry to better undertake the client briefing and design review phases of a project. DIVERCITY comprises three main workspaces, which are client briefing, design review and construction workspaces respectively Whilst the Client Briefing workspace enables architect to interact and communicate with client for capturing client needs, the design review workspace allows design team to review the design solution in different respects such as lighting, acoustic and thermal conditions and the construction workspace helps the planner evaluate optimum buildability for a building through communication with other parties of the design team and site planning and management. The paper presents the DIVERCITY system and its main six components: Client Briefing, Lighting, Acoustic, Thermal and Heating Simulations, Visual Product Chronology for construction planning, lastly Site planning & Analysis, how each of them handles different aspects of a construction project in a construction supply chain and how they complement each others to constitute a seamless integrated computer environment for the sake of excellence of briefing and design and construction planning.

1 INTRODUCTION The Construction industry is one of the major sectors with 780 billion Euros: it means that the construction industry is the largest industry in the industrial employment in

Ework and ebusiness in architecture, engineering and construction

696

Europe with 11 million workers, which equals 7% of the working population. Furthermore, owing to being dependent on the construction industry, 22 million jobs are created in other sectors (Coudret etal,2001). In the past decade, construction companies have spent a great deal of effort and resources in improving their business processes. New forms of innovative project management, supported by recent IT developments, have appeared in response to evergrowing pressure from owners to complete projects on time and deliver high quality buildings (Sarshar & Christiansson, 2004). Construction has become an information intensive industry; and a new activity has emerged from the process of managing projects, establishing itself as a discipline in its own right: information management (Construct IT 2000). Despite the interest and effort applied by leading companies, information management in the construction industry is still in its infancy (Sarshar & Christiansson, 2004). Construction projects involve a large number of direct stakeholders (clients, professional teams, contractors) and indirect stakeholders (local authorities, residents, workers). There are significant barriers to communications between the stakeholders. Many researchers have acknowledged the limitations of current approaches to the management of information in projects (Kiviniemi 1999) (Aouad, 1997) (Alshawi, 1996). Most of these limitations are due to (Sarshar & Christiansson, 2004): • Much project information is stored on paper as drawings and written documents. This is frequently unstructured and difficult to use. It is also easy to lose or damage (Construct IT 2000). Thousands of documents are shared during a typical project, leading to significant human errors in managing the versioning of these documents. • This process leads to incomplete understanding of the planned construction, functional inefficiencies, inaccurate initial work or clashes between components. • People responsible for collecting and archiving project data may not always understand the specific needs of those who will use it, such as those involved in building maintenance. • The data is usually not managed while it is created, but instead it is captured and archived at the end of the construction stage. This means that people who have knowledge about the project are often likely to have left for another project by this time—so their input is not captured. • Lessons learned are not organised well and are buried in details. It is therefore difficult to compile and disseminate useful knowledge and best practice to other projects (Watson and Marir 1994). In the past, researchers have used IT for providing numerous decision support systems for the professionals involved in the industry (Faraj & Alshawi, 1999). However, these systems have created islands of automation and are far from achieving an acceptable level of integration across disciplines and across the design and construction processes (Faraj & Alshawi, 1999), and (Kartam, 1994).

Distributed virtual workspace for enhancing communication

697

2 A VISION FOR CONSTRUCTION IT Sarshar (2000) developed a vision for construction IT. Sarshar portrayed a scenario where all stakeholders can produce their relevant project information and post it on an electronic “project information board”. Each user has appropriate access rights and can manipulate the necessary information on demand. This vision has been termed construction “integration”, by many researchers (Issa, 1999) (Alshawi, 1996). In this vision for construction IT (Sarshar 2000), the users of this information board need not be tied to their computers and office network for connections and access. Advances in communications technologies allow users to manipulate information in any format, and in any geographical location. This is known as construction “collaboration” (Sarshar & Christiansson, 2004). 2.1 Construction integration Currently, construction project information is captured in documents and 2D CAD drawings. The construction parties may share these documents and drawings using an electronic environment. But problems arise as the volume of documents and drawings and their versions increase (Sarshar 2002). The “project information board” approach is a means of sharing project information, via a shared conceptual product/process model. Information is entered once and is used by all stakeholders, during a project. Some of the benefits of the integrated approach include: • Much of the project information can be presented in a visual rather than textual format. This eases communications and information sharing (Issa 1999, Thabet 1999, Brandon 1999). • Many aspects of the building can be simulated to improve client briefing and design reviews (Sawhney 1999) (Shi 1999). • Such interactive technology can be used to consider life cycle issues such as environmental impact, space planning, facilities management, emergency evacuation, security and constructability during design reviews. This can facilitate concurrent engineering by involving clients, planners, architects, designers, civil engineers, contractors, facility managers and security personnel (Sarshar 2000, 2002). • It is easier to use past project knowledge and information for new developments (Sarshar & Christiansson, 2004). 2.2 Construction Collaboration Construction Collaboration is an area, which investigates how the supply chain can access and manipulate the “project information board”, irrespective of their geographical location. The key elements of this collaborative environment include (Divercity Handbook 2003, Christiansson et.al, 2001):

Ework and ebusiness in architecture, engineering and construction

698

• Advanced administration tools for distributed personal, team, and project information repositories; • Access to virtual building models and collaborative environments through wireless networked technologies and low cost virtual reality environments; • Appropriate security levels for sharing the information over the inter/intranets; • Process and workflow management tools to support variations in working practices between different projects; • New generations of ICT tools that facilitate collaboration and communication with endusers.

3 THE DIVERCITY PROJECT DIVERCITY was an EU funded project (1999–2002) (Divercity Handbook 2003), (Christiansson 2002). The project used IFC standards in order to develop a toolkit for shared virtual briefing and design in the construction industry. This toolkit allows construction companies to conduct client briefing, design reviews, simulate what if scenarios, test constructability of buildings, communicate and co-ordinate design activities between teams. Both synchronous and asynchronous interaction are emphasised in this framework. DIVERCITY allows users to produce designs and simulate them in a virtual environment. The designs are IFC based and can be viewed by all stakeholders within the project team. The project had the following objectives: • Creation of a client-briefing workspace, which can facilitate interaction and communication of design ideas between client and the architect • Creation of an interactive design review workspace, which can facilitate multidisciplinary design reviews involving different stakeholders of a construction project, i.e. planners, architect, designers, civil engineers, electrical engineers, contractors, facility managers, security personnel etc. • Creation of a virtual construction workspace, which can assess the buildability (the sequence of construction activities, scheduling, material handling etc) of abuilding • Specification and development of a software framework for integrating the above three workspaces and sharing them over networks to support collaboration between geographically distributed project team members.

4 THE DIVERCITY SYSTEM DIVERCITY has developed virtual workspaces that improve communication and collaboration. DIVERCITY has focused on three construction processes, i.e. (i) client briefing; (ii) design reviews; and (iii) site operations and constructability as well as communication and integration framework.

Distributed virtual workspace for enhancing communication

699

4.1 Client Briefing application The Client Briefing application; Pre CAD represents the interface between the client and design team: It is the mechanism for communication of ideas, the exploration of concepts and the presentation of the design. It is intended to produce a single initial design, agreed upon by all parties, and as this design is iteratively and progressively turned into a formal detailed design, feedback is obtained in order to drive the design process forward. Recent research carried out at the University of Salford (Barrett, Stanley, 1999) suggests that Client Briefing should not be seen as an event but as a process, which works in an iterative manner to refine the design. Figure 1 shows the DIVERCITY Client Briefing process and a Pre CAD VR environment. In order to achieve this process, the design team needs to be able to present their design to the client in a manner that the client can easily understand. This presentation process may generate new inputs into the design from either the client or the design team. These resultant inputs may be either new parameters for the design, or simple modifications that may be made at the time of the presentation. 4.2 Design Review applications In the design/Constmction process, detailed design is an important phase where the inputs are represented by a rather architectural design (usually drawings on a 1:1000 scale) and the outputs are precise definition of

Figure 1. DIVERCITY Client Briefing process and Pre CAD VR environment for Client Briefing. all technical domains related to the design, e.g. structural design, heating and thermal, lighting, acoustic, fire safety, etc (Shelbourn et al, 1999). Although state-of-the-art software tools exist for the detailed design stage, throughout the user requirements capture in the DIVERCITY project, it has been observed that these existing tools suffer from two important limitations: (Shelbourn et al, 1999)

Ework and ebusiness in architecture, engineering and construction

700

• Discontinuities between the different software tools. This makes the reuse of the results of one technical domain as an input for another technical domain practically impossible; • Lack of 3D real-time inspection features. Consequently, members of the project team spend too much time trying to (i) understand the project information (ii) to describe this information to one another. In order to greatly reduce the above limitations, in the DIVERCITY context an interactive design review workspace that allows the project teams to visualise and interact with the project on a multidisciplinary basis has been created. The main features of the design review workspace are as follows: • Supporting continuous design between different phases and within the detailed design phase using IFC (Industry Foundation Classes), which means that the calculation results yielded for one technical domain can be reused as an input for another technical domain. • Model Driven Approach that allows project teams to share the same view about the prqject through a visual and shared conceptual model. As a result substantial improvements can then be made on the communication level between the project teams. Design Review applications within the DIVERCITY scope are: • Lighting Simulation by means of which user can visualise, with a photo realistic rendering, the lighting conditions of each space taking into account both natural and artificial light sources. • Acoustic Simulations allowing the user to experience what it would be like to live and work in the spaces of the building. • Heating and Thermal simulations in order to assess both energy consumption of a building and thermal comfort conditions in each space. 4.2.3 Lighting simulations The lighting simulation module of DIVERCITY provides realistic simulation of light transfers. Moreover, it is the first time that a lighting simulation involving radiosity provides interactive solutions to the user. They can change and move objects or lights in the building and see updated simulation interactively. The lighting application will enable the user to look at different ways of lighting the spaces by clicking and dragging objects into spaces and placing them at different locations within the space. The reflections and contrasts from surfaces of flirniture, walls, windows, etc can be viewed, enabling the user to place lights in their optimal positions for best lighting in the room. Some example layouts are provided for the client or user to see how different positions affect the light in the space. Furthermore, the effect of natural daylight on the spaces can be viewed in the simulation. Figure 2 shows some lighting simulation analysis from different perspectives.

Distributed virtual workspace for enhancing communication

701

4.2.4 Acoustic simulations The acoustic module of DIVERCITY offers users the ability to automatically read the CAD-model, to interactively change materials of the building components

Figure 2. Examples of a rendered scene and object motion in the lighting simulation. (walls, floors…) and to “listen” to the acoustic environment inside a building, taking into account sound scenes inside and outside the room. Acoustic simulation enables the user to have a realistic experience of the acoustic of a space in building. It yields sounds that can be perceived by the user and used very easily to evaluate the project from acoustic point of view. 4.2.5 Thermal simulations The thermal module of DIVERCITY offers users the ability to automatically read the CAD-model yielded by a CAD tool supporting IFC export, to interactively change materials of the building components (walls, floors,) and to simulate variation of temperatures in different rooms and calculate exploitation costs. The application enables the user to obtain quick feedback on the thermal performances of the building including a realistic visualisation of the temperatures in each thermal space and relevant information about exploitation costs related to the HVAC system. The client or user can change the materials of the building in order to reach a compromise between comfort conditions on one hand and exploitation costs on the other. Thermal analysis can be a complex task taking into account diverse parameters such as building geometry, climatic environment, HVAC systems, behaviour of the occupants, infiltration and natural ventilation, air quality and pollutant transport (Shelbourn et al, 1999).

Ework and ebusiness in architecture, engineering and construction

702

4.3 Construction workspace applications The DIVERCITY construction workspace aims at providing functionality to allow for rehearsing, evaluation, and optimisation of the construction planning stage. It can be thought of as testing the constructibility of a building by assessing both temporal and spatial aspects resulting from a planned schedule so as to identify and resolve potential conflicts that would otherwise impose high costs if treated at later stages (Fernandoetal, 2001). 4.3.1 Site planning and analysis This application aims to design a modelling and simulation platform for supporting the construction site analysis stage, and allow the evaluation and optimisation of the construction site layouts. In particular, it addresses the space planning aspects by assisting with the representation and management of spatial requirements in the construction site (Tawfik & Fernando, 2001). The main functions that are carried out by the site-planning application are as follows. • Site layout initialisation: initial layout is generated by the user interacting with a VR environment and populating the construction site with different spaces (vehicles, building components, temporary facilities, etc), taking into account schedule information. Alternatively, an initial site layout is constructed from GIS or CAD data. • Safety analysis: determines the hazard zones of site spaces such as cranes, vehicles and equipment, according to their variable degree of risk and dimensions. • Space analysis: defines movement path and fields of vision for people and vehicles, and evaluates accessibility and visibility in the site. • Optimisation: the generation of a favourable spatial arrangement of the site using an optimisation algorithm, a user defined risk minimisation, space use -efficiencymaximisation and travelling cost minimisation criteria. • The Buildability Schedule provides information on the changing spatial dimensions of objects in the site over time, such as the size of the building or the material store, etc. This information could then be feedback to the site modelling and optimisation modules, to evaluate the site layout at different stages of the construction period on the site. 4.3.2 Visual Product Chronology The second application of the construction workspace in DIVERCITY is a 4D VR simulation application namely Visual Product Chronology that step by step shows how the progress a construction project will look like in practice. The application links a standard IFC based 3D building model with associated construction schedule, which can be prepared with off the shelf project management software package (Fernando et al, 2001). The first basic process of using 4D simulation application is about linking Building Model with Project Task Model. The IFC building product model provides the standard for storing all this information. The additional processes firstly cover the situation where task timings have been changed using project management software

Distributed virtual workspace for enhancing communication

703

package and there is a need to update the IFC 4D building model with this data. Secondly, the additional processes facilitate the conversions between IFC task model and the used project management software package. Afterwards, updated 4DIFC model is converted to VRML format for simulation. Subsequently, the software makes it possible to simulate the building schedule for example, day by day. The stage that will be reached at the construction site can be seen on the computer display. The easiest way to use the software is to access it by using an Internet browser, but it is also possible to take advantage of it in virtual-reality studios. Figure 3 shows the process flow and simulation display of the Visual Product Chronology.

Figure 3. VPC process flow and 4D simulation display. 4.4 Communication and integration 4.4.1 Communication layer The Communication Layer is at the heart of the distributed features of the DIVERCITY system. It provides support to allow virtual collaborative spaces at geographically distant sites to work together. The communication layer of DIVERCITY employs XML as the distribution layer for the exchange of information. The implementation of communication layer is based on SOAP (Simple Object Access Protocol) Internet protocol. One of the main advantages of SOAP protocol is that it deals with proxies and firewalls, which are often very strict in the industry domain (Da Dalto & Gobbetti, 2001). The communication layer provides the followings. • Communication between heterogeneous systems, architectures and languages. • Robust and secure messages transfer. • Time performances to allow real time collaboration (only for specific messages-3D scene motions and updates). • Multi-user management including identifications and access control.

Ework and ebusiness in architecture, engineering and construction

704

4.4.2 Product modelling IFC has been used as the product modelling technology, which was developed by the International Alliance for Interoperability (http://www.iai.org.uk/). The IFC defines a single object model of buildings shared by all IFC compatible applications. IFC project models enable the users to exchange information accurately and error-free (Christianson, et al, 2002). That is to say, an IFC sketch produced in the Pre CAD application can be distributed over the communication layer and loaded to the other DIVERCITY applications without any duplications and repetitions throughout the project lifecycle. As well as the IFC, ISO Part 42 of STEP (Standard for the Exchange of Product Data) is also employed to keep track of a geometric representation within the DIVERCITY kernel. Basing our common geometric representation on this standard has enforced common comprehension of geometry by different Data Structuring Layers (Christianson et al, 2002). 5 CONCLUSION The paper first explained the vision for integration and collaboration for the construction industry. Afterwards, it described the DIVERCITY R&D effort. The DIVERCITY project aimed at developing innovative workspace technologies for the briefing and design phases of the lifecycle. The DIVERCITY system incorporates six main applications, each of which responds some special end user requirements from early briefing to the detailed design and the construction monitoring stages. Those applications can run comfortably within the DIVERCITY framework. Output of one application can be distributed and be input to another application, which denotes a seamless integration and collaboration for the stakeholders. The DIVERCITY project has succeeded in gathering science and industry in a collaborative, exploitative and enriching workspace. The traditional barriers between special disciplines were broken down to establish collaboration scenarios based on mutual visions (Christianson et al, 2002). REFERENCES Alshawi, M. (1996) “SPACE: integrated environment” Internal Paper, University of Salford, July 1996. Aouad, G., Marir F., Child T, Brandon P. and Kawooya A. (1997) “Construction Integrated Databases—Linking design, planning and estimating, The OSCON approach”; International Conference on the Rehabilitation and Development of Civil Engineering Infrastructures. American University of Beirut, pp 52–60, June 1997. Barrett P., Stanley C., (1999) “Better Construction Briefing”, University of Salford, Blackwell Science. Aspin R., Fernando T., (2002) “Development and Exploration of Conceptual Building Function-toForm Relationships”. ECPPM 2002 European Conference of Product and Process Modelling. eWork and eBusiness in AEC, Portoroz, Slovenia. 9–11 September 2002.

Distributed virtual workspace for enhancing communication

705

Brandon, P.S., (1999) “Product Process Development in 2000 Beyond”, Berkeley-Stanford CE&M Workshop, Stanford 1999. Christiansson P., Da Dalto Laurent, Skjaerbaek J.O., Soubra S., Marache M., 2002, “Virtual Environments for the AEC sector—The DIVERCITY experience”. ECPPM 2002 Proceedings European Conference of Product and Process Modelling. eWork and eBusiness in AEC. (Editors: Ziga Turk, Raimar Scherer). Swtes & ZeitlingerPublishers, Lisse The Netherlands. ISBN 90 5809 507 X. 9–11 September 2002, Portoroz, Slovenia. (pp. 49–55). Christianson P., Da Dalto L., Skjaerbaek, J.O., Soubra S., Marache M., (2002) Virtual Environments for the AEC sector, ECPPM conference, Slovenia, September 2002, paper 465. Christiansson P, Svidt K, Skjaerbaek JO, Aaholm R, (2001). “User requirements modelling in design of collaborative virtual reality design systems”, International Conference on Construction Information Technology, Mpumalanga, South Africa. Construct IT (2000), Construction Modelling Methodologies for Intelligent Information Integration (COMMIT), Construct IT Centre of Excellence, UK ISBN 1-900491-76-1 Coudret F., Lombardo J.C., Marache M., Soubra S., (2001) A VR application for the Construction Industry, Virtual Reality International Conference, Laval Virtual, May 16th-18th 2001. Da Dalto L., Gobbetti E. (2001), DIVERCITY Deliverable 16&17: System Architecture; Multiresolution Module and Communication Services. Divercity Handbook (2003), “The Divercity Project: A Virtual Toolkit for Constructin Briefing, Design and Management”, University of Salford, UK. Faraj I., Alshawi, M., (1999), “A Modularised Integrated Computer Environment For the Construction Industry: SPACE, University of Salford, UK, http://itcon.Org/1993/3/ Fernando T., Kähkönen K., Leinonen, J., Murray N., Tawfik H., (2001) Facilitation of collaborative communication for building construction with Virtual Reality Technology, Conference on Applied Virtual Reality in Engineering & Construction Applications of Virtual Reality, October 4–5, 2001 Gothenburg, Sweden, (pp. 1–17). IFC http://www.iai.org.uk/ Issa, R., (1999) “Virtual Reality: A Solution to Seamless Technology Integration in the AEC Industry”, Berkeley-Stanford CE&M Workshop, Stanford 1999. Kartam N.A., (1994). “Interactive system for integrating CAD and computer based construction systems”, In: Microcomputers in civil engineering, Vol 9, pp.41–51. Kiviniemi, A., Laitinen, J., Lautanala, M., (1999) “Defining a Research Agenda for AEC”, Berkeley-Stanford CE&M Workshop, Stanford 1999. Sarshar M., Christiansson P, and Winter J (2004) Towards Virtual Prototyping in the Construction Industry: The Case Study of the DIVERCITY project. In: Brandon P, Li H, Shaffii N, Shen Q (Eds), INCITE Conference, 18–21 February 2004, Langkawi Malaysia. Designing, Managing and Supporting Construction Projects through Innovation and IT solutions, Vol. 1, 581–8. Sarshar, M., Betts, M., Abbott, C., Aouad, G.,(2000) “A Vision for Construction IT 2005–2010”, RICS (Royal Institute of Chartered Surveyors) Research Series, Dec 2000. Sarshar, M., Tanyer, A., Aouad, G., Underwood, J., (2002) “A Vision for Construction IT 2005– 2010: Two Case Studies”, Engineering, Construction & Architectural Management, Issue 2, April, 2002. Sawhney, A., (1999) “Research and Development Plan for the AEC Industry”, Berkeley-Stanford CE&M Workshop, Stanford 1999. Shelbourn M., Soubra S. & J.Martin, (1999) DIVERCITY Project Deliverable 8, Design Review Workspace. Shi, J.J. (1999) “Computer Simulation in AEC and its Future Development”, Berkeley-Stanford CE&M Workshop, Stanford 1999. Tawfik, H., Fernando, T. (2001), “A simulation environment for construction site planning”, The 5th IEEE International Conference on Information Visualisation, London, UK, 25–27 July 2001. Thabet, W., (1999) “Design-Construction Integration Through Virtual Construction for Improved Constructability”, Berkeley-Stanford CE&M Workshop, Stanford 1999.

Ework and ebusiness in architecture, engineering and construction

706

Watson, I.D., & Marir, F. (1994) “Case-Based Reasoning: A Review.” The Knowledge Engineering Review, Vol. 9(iii), pp. 327–54.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Cooperation and product modelling systems S.Blokpoel Civil Engineering and Management, University of Twente, the Netherlands R.P.M.Jongeling & T.Olofsson eBygg—Centre for Information Technology in Construction, Luleå University of Technology, Luleå, Sweden ABSTRACT: This paper deals with the introduction of product modelling in today’s building process. The main potentials of these systems are facilitating open communication, configuration management, reuse of information, virtual prototyping (such as 4D) and allowing numerous analyses on e.g. life cycle, energy use and accurate estimates of project costs. The modelling systems have prerequisites for application that are not fulfilled by the construction industry today. Therefore, the potential benefits cannot be derived at the moment. Most unfulfilled prerequisites are related to the way of cooperation. New building process organisation types, like partnering, offer a better way to approach a project and a good basis to use the systems. The development of these organisation types should be integrated in the application of models because the systems could be a good tool, and maybe even an enabler for partnering. This synergy can be the basis of improvements in the construction industry.

1 INTRODUCTION Since several years, product models are beginning to be adapted in mainly the design processes of construction projects. Within the actual building process the application is limited. However, demand is growing for a broader application of product modelling systems and a sharp increase of their application is expected in the years to come. While developing product models and systems, developers implicitly developed prerequisites for the use of these models. If these prerequisites are not fulfilled by the construction industry, the potential benefits of the product models will not come forward. This paper describes a pilot study (Blokpoel 2003) where the application of product models in construction and the consequences for the cooperation in these projects have been investigated. Especially the relation between partnering as an emerging building process organisation model and the potential use of product modelling has been evaluated. From this analysis we derive directions for implementation and future research.

Ework and ebusiness in architecture, engineering and construction

708

2 PRODUCT MODELS AND EXCHANGE OF INFORMATION A product model for the construction industry can be described as formal set of descriptions. Laitinen (1998:53) and Schenck (1994:55) describe the product data technology as a set of IT methods, tools and standards for the development and implementation of applications for the management, exchange and sharing of product data. The product data that is stored in the model is defined by Karstila as a representation of information about a project in a formal manner suitable for communication, interpretation or processing by humans or by computers. This information concerns both process as product information (Amor 2001) such as information on geometry, planning, costs and work-documents. Product models conceptualise a defined part of the real world. In these conceptual models, entities and their relationship are set up in a formal language to describe reality. The information can be created, exchanged and stored by various applications using a comtnon interface to the product model. This interface can give access to the entire model or only parts of the available data. Exchange files can be used to exchange the data directly between various actors or a product model server can be used to give online, direct access to the instantiated product model (Jongeling 2003). This difference can have great influence on the usability and the relations between cooperating actors in a building process. The current practice and possible exchange processes using a product model schematically describe in figure 1. In the current process, situation A, actors exchange information almost in a random matter. The same

Figure 1. The current exchange of information (A) compared to the

Cooperation and product modelling systems

709

possible exchange process with different product models (B, C and D) (Blokpoel, 2003). information is often created as much as 6 times (Laitinen 1998). In situation C, actors save their information, created by different software applications, in an exchange file and send this file to other actors. One common interface is used to access the shared model server. Situation B uses a “shared” model server were data is online and available in a central repository to all the actors directly. Situations D, uses the same exchange file as in situation C, but stores this file on an exchange server, so that other actors can retrieve this file and use it in their own software applications, after which they upload it again. The exchange scenarios involving product models (B, C and D) will put different prerequisites on the organisations using the modelling systems. For example in situation C and D the handling of versions and history of the product model is put on the organisation of the project. In situation B these tasks can be automated by the shared product model server. However, other prerequisites, such as trust and insight to project iriformation for involved actors are valid for all exchange scenarios using a single product model. 3 POSSIBILITIES In this paragraph the intended benefits for the building process are outlined. These are explicitly stated goals of the systems and (implicitly) derived potentials. These potentials are proven to be possible in practise and are not just theoretical potentials. The possibilities have been divided into four different categories, as displayed in figure 2: – Project management – Communication process – Organization process – Product development.

Ework and ebusiness in architecture, engineering and construction

710

Figure 2. Possibilities of product modeling system in the different processes of a building project (Blokpoel, 2003). The first evident potentials of a product model are the project management tasks, and especially configuration management. This consists of (Duhig 1996): – Conflguration management. The management of the deliverables in a project, both products and management products. The configuration management identifies, controls, tracks and protects these products. This includes version and status control of products that can only be changed with the relevant authority. – Risk log. The administration of identified risks. The consequences, chance of occurrence, dependencies, control actions and response actions are administrated. – Quality log. The administration of the quality control. Once deliverables have passed the quality control, their status changes to ‘ready’. Result of the control such as measure methods, responsible actors, shortcomings and consequences of that are administrated as well. Communication is the cornerstone of a project (Mohamed 2003). Today’s business and project organizations are based on management of information and knowledge; it has become the most important production factor (Egbu 2002). As mentioned before, project management task consists of 75–90% of communication (Alshawi 2003). It is essential

Cooperation and product modelling systems

711

that the right people communicate, on the right levels of different organisations. A product modelling system makes different information flows explicitly possible. By using a product model, the communication can go more efficient, more accurate, direct and at any time. The benefits for an entire project organization are rather abstract. A project organization is responsible for the business cases of the different actors as well. Modelling systems are project based systems. Product modelling systems make the integration of different phases possible (Fischer 2002). In this way, costs are saved, time is won and quality (both in product quality and in performance) is guaranteed. This is explicitly done by e.g. the better communication. But considering a project with a more business orientated view; other derived benefits can explain the eventual benefit of saving costs and time: – First of all, a product modelling system makes it possible to focus more on actual value adding activities than on processes (flows) around them. This tnakes lean (efficient) production possible and can enlarges the margins (Koskela 1992). – Product models can contribute to integration of the process in three directions (1) between the various actors, (2) between various phases and (3) between the various projects (Laitinen 1998). The product development can be improved. A model allows an improved prediction of time and costs in the early phases, allowing a client to make the right decision about the extension or reduction of the design (Suhanic 2001). Finally, by using a product model, a designer uses time more efficient. Details and different views can easily be withdrawn from a product model. In this way, he saves time to focus on the actual creative part of his job and to cooperate with the client and the other actors to ensure the quality of the design and the performance criteria of the client (Laitinen 1998). 4 PREREQUISITES Prerequisites for the use of product modelling systems are made implicitly, but can keep a system from being successfully used. The most important part of a product modelling system is the storage of data and the information exchange between the various actors. A prerequisite is that the information exchange and the use of information in a modelling system is greater than the sole digitalisation of current documents (Laitinen 1998). Another mayor prerequisite is that actors actually open there internal information to other actors in a project (Adriaanse 2003). If actors do not do that, the potential advantages for project management and communication do not come true. It is a prerequisite that the project organisation has one project management board that manages the entire project containing all the phases. In this way, the potential benefits on configuration management can be derived. Looking at the decision making process, a prerequisite is that the decisions are made on demand, at any time needed in the model. Next, a prerequisite is that all actors in a building project have the same goal of building a good building, with the intended specifications, within the planned time and costs;

Ework and ebusiness in architecture, engineering and construction

712

creating customer value. A product model can only be designed for the goal of the project and will otherwise not function as desired (Suhanic 2001). Although product modelling systems are developed for a project, the intended use for a specific company is for multiple projects. Old information can be reused and, looking at cooperation, long term cooperation with other parties can be pursued. This long term relationship is needed to get the full benefits out of the model. Concerning legal issues, the use of a product modelling system contains a number of prerequisites. First of all, the previously mentioned authority to make decisions must be based on digital documents. Suggested designs, costs, changes and many other subjects must be agreed for on in digital document or system. The supplementary need is that this document is unique and has a version and date attached to it, as the models suggests to eventually have multiple documents of the same object due to ‘easy to implement changes’. The documents must have a legal basis by which the tasks and responsibilities of the involved parties are compulsory. Next, errors can occur in exchange files due to conversion or wrong interpretation. Actors should be responsible for own made/converted information and perform a check on their data, certifying it with a digital signature. It is a prerequisite that actors take this responsibility. A log file of all exchanged data, decisions, etcetera is needed. This file should be kept at a third party, being updated with digital signatures in an encrypted data format. This ensures a proper legal relation and the possibility to fulfil the contract. Furthermore, the clear ownership of the information is a prerequisite of a product model. The information that is entered in a product model should belong to a certain party, or otherwise be destroyed after the completion of the project. One of the (potential) benefits of a modelling system is the reuse of information. Except, not all project data has to be shared. By using a middleware and a core data model only relevant parts are exchanged, decreasing the risks for errors, sharing classified information, changing internal company systems or exchanging irrelevant detail levels. Companies can connect to the (core) product data model by using a standard slot and connect their internal systems to the relevant module for specific activities, such as cost calculation. This prerequisite is closely related to the one concerning the mutual project goal. If actors try to manipulate information, communication and other actors for their own advantages; this will damage the potentials of the system.

Cooperation and product modelling systems

713

Figure 3. Partnering project organisation (NCC, Sweden, 2003). New ways of cooperation are needed to derive all benefits; a mutual goal, central project management, open communication, direct notification, involvement of the main actors in the early phases, iterative design loops and sharing of risks are necessary. 5 PARTNERING Partnering is a relative new concept in the construction industry. Since the middle of the ninety’s, a number of actors in the industry has tried a new way of working together. Partnering is seen as a social cooperation method and a basis for a learning organisation. Partnering is setting up the project together with the main actors in the project, and trying to act as partners, not as opponents. Figure 3 displays a partnering project organisation. The main actors (mostly the client, the designer and the contractor) form a platform to share risks and profits and to set mutual goals to reach high customer value for the client. In the Project Start-up, a shared vision on the way of working must be agreed on. It has

Ework and ebusiness in architecture, engineering and construction

714

no use of putting these agreements in a contract, because then the whole thought of partnering will be lost. A definition that summarizes some existing opinions of partnering is: “Partnering is a (possible long term) commitment between two or more organisations for the purpose of achieving specific business objectives by maximizing the effectiveness of each participant’s resources. This requires changing traditional relationships to a shared culture without regard to organisational boundaries. The relationship is based on trust, dedication to common goals, and an understanding of each other’s individual expectations and values (Briscoe 2001).” Project partnering is a high-risk high-gain approach (gain share, pain share). By opening up business processes to other actors, an actor is vulnerable to be abused. Especially in a sector where high risk avoidance and focusing on company goals instead of project goals is common. This means that partnering can be compared with the prisoners’ dilemma. The dependencies between two or more actors are high. The behaviour of one actor affects both its own success and other actors’ successes. Positive behaviour of all actors creates synergy and a positive project result for all actors, negative (or: strategically) behaviour will lead to minor results for all actors involved. Keywords in partnering are (Carr 1999): – trust – open and effective communication – commitment from senior management – clear understanding of different parties’ roles – consistency of objectives – flexibility to change – continuous improvement. Within a partnering organisation, a total openness of information is given and an effort is done to understand each actor’s dependencies and issues. Communication is one of the most important parts of partnering. Partnering will not take away the cause of problems in the building process. Changes in the environment and at the client will always occur. Partnering creates a way to deal with those errors and solve them quickly without getting into a formal dispute. These benefits are the cause of fewer claims and lawsuits because (Kruus October 2003): – Problems are solved in the project team; – Problems are avoided due to good communication; – Insight in other actors’ processes. The risk allocation is an important cause for behaviour in a project. The complexity, the project view and the lack of trust are reasons for risk avoiding behaviour, such as opportunistic behaviour, legal claims and strategic communication (Dorree 2001). The soft word of ‘trust’ turns out to be important in partnering. The inappropriate risk allocation is also a source for mistrust. The lack of trust is another cause for e.g. opportunistic behaviour. Without trust, actors feel the threat of being misused and, again, try to avoid risks. The issues and behaviours above lead to the major shortcomings in the sector; errors due to e.g. poor communication, budget and time exceeding projects, mismatch between requirements and the eventual product. The lack of a central project

Cooperation and product modelling systems

715

management (and thus configuration management) is one of the technical causes for errors in communication; others are behavioural such as strategic communication. The paradox of Bresnen states that a complex environment needs specialists, but also coordination between those (differentiation versus integration); needs contracts to allocate risks, but also flexibility. These paradoxes can only be undone with sufficient trust, for which mutual goals, a project view and open communication is needed in a project. To derive these benefits, a partnering organisation needs tools to actually make an improved communication and an open organisation possible. Good communication is essential for partnering. The right actors have to be reached at the right time, and relevant information has to be communicated. The unwillingness to share information and open up ones business process is a great threat for partnering. Steps to come to partnering are first of all to pay attentions to the keywords. But giving the facts that partnering also means taking responsibility to try and pursue a good project, the right start for partnering is at an individual company. 6 MATCHING From the sections on the prerequisites and partnering it can be concluded that in a partnering project, most imminent prerequisites are fulfilled. In the research leading to this paper, the potential possibilities of the modelling systems and the prerequisites have been outlined in a matrix. The matrix was ordered in project management, communication, organisational and product development. Scores in the matrix indicated which possibilities of the systems were dependent of prerequisites. It turned out that the most crucial part was the organisational prerequisites. Once further research showed that these prerequisites were not fulfilled at all by the current construction industry, more focus was given to new ways of cooperation. To verify the results from theoretical research, projects in Helsinki, Finland, were examined. The construction of a new headquarter for NCC Finland, application of design analysis by Granlund and the HUT600 pilot project were examined, mostly by interviews. In most of these projects, the relative good match between needs of the construction industry and potentials of the systems were confirmed. The nature of the projects confirmed as well that close cooperation was needed for mayor project advantages. Next to that, it was found that internal company benefits can form a good start for applying modelling systems. 7 DISCUSSION The construction sector is strongly project based, each project is unique and produces a prototype as final product resulting in risks and uncertainty, the projects are divided in phases that are often strongly separated and there is a lack of long term vision. The risk allocation is an important cause for behaviour in a project. The complexity, the project view and the lack of trust are reasons for risk avoiding behaviour, such as opportunistic behaviour, legal claims and strategic communication:

Ework and ebusiness in architecture, engineering and construction

716

– The inappropriate risk allocation is also a source for mistrust. The lack of trust is another cause for e.g. opportunistic behaviour. Without trust, actors feel the threat of being misused and, again, try to avoid risks; – The issues and behaviours above lead to the major shortcomings in the sector; errors due to e.g. poor communication, budget and time exceeding projects, mismatch between requirements and the eventual product; – The paradox of Bresnen states that a complex environment needs specialists, but also coordination between those (differentiation versus integration); needs contracts to allocate risks, but also flexibility. These paradoxes can only be made undone with sufficient trust, what needs e.g. mutual goals, a project view and open communication in a project; – The needed change in cooperation such as open, errorless communication and the reuse of information needs tools to facilitate these changes. The potential advantages of product modelling systems seem to offer possibilities to improve the construction sector. But the, often implicit, prerequisites for the use of the models keep the advantages of coming true. Partnering offers a new way of cooperation by which the construction sector fulfils in most of the important prerequisites. By using partnering, the potential advantages of the modelling systems can actually improve the construction sector. In that way, there is a great synergy between partnering and product modelling systems as displayed graphically in figure 4.

Figure 4. The application of product modeling systems in different Building process organizations (Blokpoel 2003).

Cooperation and product modelling systems

717

8 CONCLUSION Product modelling systems offer possibilities to the construction sector that match relatively good with the needs of the sector. These needs come forward from the main shortcoming in the sector; a lack of a common project view of the different parties involved, an inappropriate allocation of risks, firm contracts and price focussed organisations. Important consequences of these shortcomings are opportunistic behaviour, strategic communication, errors due to old, wrong or irrelevant documents, a mismatch between the client’s requirements and the eventual product and time and budget exceeding projects. The application of modelling systems is not the ultimate solution for the construction industry. Solving the shortcomings of the construction sector is a relevant goal; modelling systems can be a useful tool, and maybe even an enabler for change. Most of the unfulfilled prerequisites are related to the way of cooperating between different parties in a project. New building process organisation types, like partnering, offer a better way to approach a project and offer a good basis to use the modelling systems. By taking trust as a basis, defining a mutual project goal for the main actors, communicate openly and understand other actors’ processes a lot of the shortcomings can be taken away in a project. Product modelling systems can be a good tool for this development, and maybe even an enabler. The potentials of the models are to facilitate an open communication, a good configuration management, more reuse of data and virtual prototyping in 4D. The application can result in fewer errors, better decision making, more insight for the client, more efficiency and better (performance) quality in a project. Legal issues are no roadblock, but need attention. The current contracts are sufficient, but need an add-on for procedures in the use of ICT. A third party should keep an encrypted log file to ensure traceability of changes. Model errors in exchange files can occur and cause problems. Producers of data should be responsible for the produced data and check it on consistency. A middleware is needed to exchange only core model information and to allow company based ICT systems that connect through a shared modelling system. The promising opportunities for facility management with as-build product model data could be the right initiator for a building owner. At all time, a company’s internal ICT benefit should be started with. The research on, the development of and the application of product modelling systems should go hand in hand. The focus should be on application of the models in practice with small steps, while at the same time focusing on: – Application in individual companies, gaining internal benefits first; – Developing KPI’s for the measurement of results and the business justification; – Developing modelling systems on indicated issues; – Combine application with new or improved ways of cooperation in the construction industry, like partnering. The very first steps should be taken in the individual company; where internal benefit must be reached. ICT strategies and employee training should set a basis for changes. In

Ework and ebusiness in architecture, engineering and construction

718

cooperation, especially the search for trust is important. Partnering is a useful concept, and can be further exploited. Research on Product modelling systems should focus on following the actual application and supporting a stepwise introduction, developing a proper middleware with a definition of core models and solving practical legal issues. ACKNOWLEDGEMENT The financial support from SBUF—Development Fund of the Swedish Construction Industry, NCC and the Centre for Information Technology in Construction (eBygg) at the Luleå University of Technology is acknowledged. REFERENCES Adriaanse, A. M., Voordijk, H., Dewulf, G.P.R.M. 2003. Alignment between ICT and Communication in construction projects. Human Resources Development and Management (35): p. Alshawi, W., Ingirige, B. 2003. Web-enabled project management: an emerging paradigm in construction. Automation in Construction. 12(6): p. 349–364. Amor, R., Faraj, I. 2001. Misconceptions about integrated project databases. IT in Construction (ITcon). 6(37): p. 57–68. Blokpoel, S.B. 2003. Cooperation and product modelling systems; the application of product modelling systems in the building proces. Research report 2003:17. Luleå, Sweden: Luleå University of Technology. Briscoe, G., Dainty, A.R.J., Millett, S. 2001. Construction supply chain partnerships: skills, knowledge and attitudinal requirements. Purchasing & Supply Management. 7(29):p. 243–255. Carr, F., et al. 1999. Partnering in construction. Chicago, USA: American Bar Association Publishing. Dorree, A.G., et al, 2001. Bouwprocessen. Enschede, The Netherlands: University of Twente. Duhig, B., Atkins, W.S., Penzer, A. 1996. Managing successful projects with PRINCE2. London, UK: CCTA, The Stationary Office. Egbu, C.O., Borrerill, K. 2002. Information technologies for knowledge management: their usage and effectiveness. IT in Construction (ITcon). 7(13): p. 125–137. Fischer, M., Kam, C. 2002. Product models 4D. Stanford, USA: CIFE Stanford University. Jongeling, R.P.M. 2003. Product models for cast in place concrete. Luleå, Sweden: Luleå University of Technology. Koskela, L. 1992. Application of the new production philosophy to construction. Stanford, USA: CIFE Stanford University. Kruus, M. October 2003. In. Göteborg, Sweden: NCC Sweden. Laitinen, J. 1998. Model based construction process management. Stockholm, Sweden: Kungl Tekniska Högskolan (KTH). Mohamed, S., Stewart, R.A. 2003. An empirical investigation of users’ perceptions of web-based communication on a construction project. Automation in Construction. 12(4):p. 43–53. Suhanic, G. 2001. Computer aided project management. New York, USA: Oxford University Press. eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Linking early design decisions across multiple disciplies R.Drogemuller, J.Crawford & S.Egan CSIRO Division of Manufacturing and Infrastructure Engineering, Highett, Australia ABSTRACT: The early stages of the building design process are when the most far reaching decisions are made regarding the configuration of the proposed project. This paper examines methods of providing decision support to building designers across multiple disciplines during the early stage of design. The level of detail supported is at the massing study stage where the basic envelope of the project is being defined. The block outlines on the building envelope are sliced into floors. Within a floor the only spatial divisions supported are the “user” space and the building core. The building core includes vertical transportation systems, emergency egress and vertical duct runs. The current focus of the project described in te paper is multi-storey mixed use office/residential buildings with car parking. This is a common type of building in redevelopment projects within and adjacent to the central business districts of major Australian cities. The key design parameters for system selection across the major systems in multi-storey building projects—architectural, structural, HVAC, vertical transportation, electrical distribution, fire protection, hydraulics and cost—are examined. These have been identified through literature research and discussions with building designers from various disciplines. This information is being encoded in decision support tools. The decision support tools communicate through a shared database to ensure that the relevant information is shared across all of the disciplines. An internal data model has been developed to support the very early design phase and the high level system descriptions required. A mapping to IFC 2×2 has also been defined to ensure that this early information is available at later stages of the design process.

1 INTRODUCTION Building projects follow the Pareto Principle or 80:20 rule, where 80% of the decisions affecting the project outcome are made during the first 20% of the project’s life. Thus the decisions made early in the design process have the most far reaching consequences and should be made with an appropriate level of care. However, this stage of the design process is poorly supported by current CAD systems. The aim of the project described in this paper is to assess how well three major architectural CAD systems and a CAD system aimed at mechanical design, support the parametric description of building

Ework and ebusiness in architecture, engineering and construction

720

designs across multiple disciplines. While the results of the comparison are not yet complete, this paper describes the current status of the project and the deliverables to date. A side effect of the main deliverable is the implementation of a decision support system for the early stage of building design that interfaces with four different CAD systems. This demonstrates the benefits of interoperability in providing shared information services. This is one of the projects supported by the Cooperative Research Centre for Construction Innovation (CRC CI) (CRC CI, 2004) as part of its charter to change the way that the AEC-FM industry operates. Some of the deliverables from previous projects have been adapted to suit the needs of early design problem solving. 2 IDENTIFYING KEY SYSTEMS The starting point of the project was to identify the major building systems that should be considered during early design. Discussions with the industry partners and a literature review identified these key systems and the relevant parameters within the systems. Systems were only chosen if they had major implications for the shape and layout of the project. The systems selected were: • Architectural spatial layout • Structural • Environmental • Fire protection • Hydraulics • Electrical • Vertical transport • HVAC • Cost/budget The types of projects and the level of detail used are illustrated in figure 1.

Linking early design decisions across multiple disciplines

Figure 1. Massing model with storeys. Upper shaded floors are residential, middle floors are office space, lower levels are below ground car parking. Lift overrun on top represents the building core.

721

Ework and ebusiness in architecture, engineering and construction

722

3 BUILDING SYSTEMS Even at the early stages of design with which we were concerned each of the building systems is interdependent with the others. We were not able to identify any one view that could be modeled independently of the others. We were also not able to identify one system on which there were no dependent systems. Each of the “design advisors” within the software has its own “view” of the shared information in the database. The development of the advisors has assisted in defining these specialist views at the early design stage. An overarching parameter that applies to all building services systems is the “quality” or level of service that the building will provide. Normally the rental return on a building will be closely linked with the quality. In Australia and, presumably, in other countries, there is a list of requirements for the various “grades” of office accommodation which make the requirements very explicit. The rental charged on space is then negotiated with this standard as the starting point. 3.1 Architectural spatial layout The way that spaces can be laid out depends on the type of space and how flexible it needs to be over the proposed life span of the building. The types of “user” space that are handled in this system are residences, office accommodation and car parking. All of the space types have a scaling factor applied to allow for shared communication space. For example, the area of residential units is scaled up by a factor that caters for corridors and lobbies that are shared on a floor. This factor is user configurable to allow adjustment for different layouts and requirements. Residences are treated as a single space representing the entire unit. The parameters that are used cover the number of bedrooms and the “standard” of accommodation based on local real estate categories. Connection points for the plumbing are also required to assess whether a vented stack is required or not. Constraints on the minimum width of the space are applied and some adjacency to an external wall, for views and ventilation, is required. The requirements for services are applied to the unit as a whole since they do not vary much within a residential unit. The office accommodation is much simpler to handle from a geometrical perspective since most office accommodation is designed to be flexible. There are no inbuilt constraints on shape or adjacency to external walls although these can be added. There is an increased requirement for detail on the building services. Briefing documents from completed projects were used to define a standard template for space data. The space data is aggregated under user control to provide the appropriate level of granularity for the particular design requirements. The information stored for office spaces includes: • Location/access requirements—public or private space, access to other spaces. Etc • Occupancy—number of people • General surface finishes

Linking early design decisions across multiple disciplines

723

• Environmental control—HVAC, naturally ventilated, etc • Hydraulic requirements—water supply and drainage • Sanitary fixtures • Electric power and lighting requirements, including heat generating equipment • Communication system requirements • Security requirements • Special fixtures—any non-standard fixtures or fixtures that will affect the provision of building services. Not all of this information is currently used but it was considered important to maintain continuity of information from the brief ing stage through this very early design stage. As van Leeuwen & van Zupthen (1994) recognised, even at this stage the functional requirement/technical solution concept of GARM (Gielingh, 1988) is useful. The requirement of Xm2 of general office space is met by the physical solution of floors 3–7 of the proposed building. 3.2 Structural system The current modeling and implementation of the structural system is fairly crude. It relies on lookup tables to estimate the size of columns and beams for reinforced concrete and steel framed construction. The inputs required to estimate member sizes are the spacing of columns in both directions and the storey height between floors. It is assumed that the building core provides sufficient stiffness for the structure. While this is a crude solution it gives satisfactory results for this stage of the design process. Future work is planned to improve the scope of this module by refining the available structural systems and adding alternative structural systems. 3.3 Environmental system The environmental analysis system is provided by a modified version of LCADesign (Tucker et al, 2003). An automated take-off module provides the quantities of all building components. The specific production processes, logistics and raw material inputs are identified to calculate a complete list of quantities for all products such as concrete, steel, timber, plastic etc. This information is then combines with the life cycle inventory database, to estimate key internationally recognised environmental indicators such as CML, EPS and Eco-indicator 99. The original version of LCADesign requires a detailed breakdown of the quantities of the materials in the building. The revised version uses default reasoning to infer the likely material breakdowns of the project given system level descriptions of the building. For example, if a reinforced concrete structural frame has been chosen, the structural module gives the number and size of columns and beams on a floor and the thickness of slabs. This provides all of the information necessary to calculate the volume of concrete and to estimate the amount of reinforcing steel required. The area of formwork required can be estimated to a reasonable level of accuracy from the floor area of the slab multiplied by a scaling factor plus the surface area of the columns. This information can then be aggregated with the information from other systems to provide whole of building results.

Ework and ebusiness in architecture, engineering and construction

724

The required inputs are the geometry of the building and indications of the overall physical building system configurations. The outputs are graphs that allow assessment and comparison of the building performance. 3.4 Hydraulics The hydraulics system is concerned about two issues—identifying needs for water storage within the building and passing this information on to other components and ensuring that vertical service ducts are appropriately located within the building envelope. The population of the building provides the necessary information for the estimation of tank sizes. The output is a requirement for a tank size in floor area and headroom. 3.5 Fire protection Fire protection systems are pervasive in modern multistorey buildings. Local building regulations will often mandate the type of system that must be used for buildings of various heights, occupancies and areas. The applicable input parameters in Australia are the building height, area and occupancy type. The outputs are whether an automatic sprinkler system is required and if so, the capacity of any storage tanks, whether a fire control centre is required and whether diesel/electric booster pumps are required. Assessment for smoke protections systems could be added in the future. 3.6 Electrical The major impact of the electrical system in the early stages of design is in deciding if a substation is necessary in the project and if so, where it should be located. Obviously, on large sites this may not be a major constraint, but on smaller, highly developed sites this can be a major decision. Whether a substation will be needed can be identified by taking the area of the building and applying a load density appropriate for the particular usage(s). Electrical loads from the other building services systems, especially HVAC also need to be factored in. This gives the total estimated load, which can be used as a basis for discussion with the local supply authority. If a substation is required the size can be given in a simple lookup table based on the total electrical load. Other spaces which may be needed include: • Switch room • Batteryroom • Emergency generator However, at the level of detail at which we are working these can normally be added to the substation.

Linking early design decisions across multiple disciplines

725

3.7 Vertical transport The choice of vertical transportation system depends heavily on the height of a building, the usage, the population and the standard of the building. Slower installations may be appropriate in smaller buildings or where the standard is lower. Once a system is selected, the number of floors served, the population of these floors, maximum waiting times and usage patterns all provide input into the number of lifts and the capacity and speed of the lift cars. 3.8 HVAC The HVAC system is often the most expensive services system and has significant impacts on the spatial configuration of a building. One of the first considerations is whether to have a centralized systetn that services many floors or to have a separate system on each floor. Either choice has its advantages and disadvantages. If a centralised system is chosen then the location and size of the vertical air conditioning ducts is significant. The most important factor is the number of occupants, which is normally estimated from the usage type and the floor area. The required values of airflow, heating and cooling load can then be looked up. Obviously the external environment also plays a role in HVAC loads so a load factor can be applied for locations where explicit data is not available. If data on the external envelope of the building is also available then the estimates can be made more accurate. This is an appropriate time to assess various alternative external envelopes and HVAC system selections to ensure that the most appropriate choice is made. Once the overall loads have been determined and a system selected the plant room requirements can then be estimated. When the plant room location(s) has been selected and loads per floor calculated the duct sizes for the vertical ducts (if necessary) can be calculated and vertical duct positions determined. This then allows the horizontal duct sizes to be determined. If necessary the floor-to-floor height may need to be adjusted before going through the loop again. 3.9 Cost/budget The cost implications of the project are obviously determined by the decisions made for all of the other systems. However, projects have financial constraints so cost implications can provide a significant constraint on the selection of the other building services systems. The use of cost planning methods to control project budgets through the design/construction process and also when trading off between systems is well understood (ie. Ferry & Brandon, 2002). Currently an overall budget is entered as a cost constraint. The cost module uses user defined rules and unit rates to calculate a cost estimate based on elemental data extracted from the shared model. Where necessary information is not directly available it is derived using inference rules.

Ework and ebusiness in architecture, engineering and construction

726

The quantities are shared with the life cycle assessment module through a shared quantity calculation module that writes the calculated quantities back into the shared database. In some instances different quantities are required across the life cycle assessment and cost modules due to differing classifications of building systems and elements. 3.10 Server database The server database uses the EDM Express server (EPM Technology, 2004). This provides single writer/ multiple reader capabilities that comply with the ISO 10303 standard. A connection manager has been implemented as an interface to the EDM server to handle the event notification required to keep all of the co-operating components synchronized. The EDM Server can store multiple projects by storing them in separate repositories. Within each repository there can also be multiple models. This provides a useful mechanism if there is a need to store different versions of the one project model for comparative analysis. Separate models are necessary if two alternatives differ in more ways than just substituting one material for another within a building component. For example, if a steel frame was being compared with a concrete frame it may be necessary to use different column and beam spacings to produce efficient structural designs for each construction type. Trying to track such alternatives within a single model is difficult. It is easier to clone the entire database and then vary one of the copies to suit the new alternative. 3.11 CAD customisation The CAD customisation provides the interface between the inbuilt facilities offered by the CAD software and the information stored in the shared database. The implementation consists of three functions: • User interface elements that provide access to the information and services that underlie the entire system; • Data import facilities that read the information in the shared database and convert it to the internal structures necessary for manipulation within the CAD system; and • Data export facilities which map the internal information on to the schema used in the shared database.

Linking early design decisions across multiple disciplines

727

Figure 2. Overall systems software architecture. 4 SOFTWARE ARCHITECTURE The overall system architecture (figure 2) consists of three levels:

1. The user interface is provided from within the CAD system. This is the sole interface to the various services which sit behind it. 2. The shared database which provides access to all of the shared information within a project. 3. The individual components which read and operate on the shared information within the database. An “event” model has been defined to support the interaction between the various components. This is a synchronous model that assumes that only one human is interacting with the system at any particular time.

Ework and ebusiness in architecture, engineering and construction

728

5 SERVICE COMPONENT ARCHITECTURE The structure of each building service design component is very simple. The EDM server provides a shared database where all of the information that must be available to others components can be stored. Within the component itself the inference mechanisms recognize particular facts or groups of facts and draw conclusions from these facts and then add the new information into the shared database. When necessary, non-project specific information, such as unit rates in the cost estimating component, are stored in a private database. This private database can also be used as a persistent store for project specific information that is not needed by other components.

Figure 3. Structural model in CATIA (RMIT).

Figure 4. Individual component software architecture.

Linking early design decisions across multiple disciplines

729

6 CURRENT STATE OF IMPLEMENTATION The planned completion date for the project is October 2004. The status in June 2004 is that initial implementations of the Autodesk ADT and the Dassault CATIA interfaces to the EDM Server are complete. The simpler components have been completed but several of the more complex components still require more work. 7 OVERALL AND LONG TERM STRATEGY This work is one aspect of the work being undertaken by the CRC for Construction Innovation (CRC CI, 2004). The major effort in IT deliverables to date within the CRC CI has focused on the information and functions occurring at the end of the documentation phase when a comprehensive and detailed three dimensional product model is available. This has allowed the definition of the information requirements for a fully populated model. This project has moved to the start of the building design process and is examining which information is available at the early design stage, how this information is generated and used and methods for supporting designers in their decision making and examination of alternatives. Future projects will then examine the information requirements during the intermediate stages of building design. 8 FUTURE WORK One of the overarching aims of the CRC CI is to change the way that the AEC-FM industry works. A suite of projects (CRC CI, 2004) are developing ICT deliverables which will provide wide support for the design and construction process. This project is unashamedly taking a pragmatic approach to supporting the design process. The focus is on what can be done now, to improve existing tools, to provide benefits to building designers in the very near future. The longer term strategy is to use this first generation of deliverables as a test bed which will then be used as a basis for the next generation of design and construction support tools. As part of this strategy, more formalized methods of viewing information and providing decision support are being examined. One promising approach, which will be examined and tested over the next few months, is “perspectors” (Haymaker, 2003). It is expected that other methods will be tested subsequently. One important capability that has not been addressed in this project is collaboration between designers within a discipline and between designers in separate disciplines. The need for collaboration gives rise to many other issues that will also be taken up in future projects.

Ework and ebusiness in architecture, engineering and construction

730

ACKNOWLEDGEMENTS This paper describes work undertaken in CRC for Construction Innovation project 2002– 060-B, “Parametric Building Development during Early Design”. The authors acknowledge the contributions of Professor Mark Bury, Julian Canterbury and Alison Fairley of RMIT, Peter Bowtell of Arup Australia and David Marchant of Woods Bagot. REFERENCES CRC CI (Cooperative Research Centre for Construction Innovation), 2004, http://www.construction-innovation.info/ourprojects.php Drogemuller, R. An ICT Platform for AEC, Proc. INCITE 2004, Bejaya Beach Resort, Malaysia EPM Technology, 2004, www.jotne.com/epmtech/ Ferry, D.J. & Brandon, P.S., 2002, Cost Planning of Buildings Gielingh, W.F., 1988, General AEC Reference Model, TNO Tech. Rep., P.O. Box 46 2600 AA, the Netherlands, BI-88-150, October Haymaker J., Suter, B., Fischer, M., and Kunz, J., 2003, “The Perspective Approach: Enabling Engineers to Construct, and Integrate Geometric Views to Generate an Evolving, Integrated Project Model Working Paper Nr 081, CIFE, Stanford University Parlour, R.P., 1990, Air Conditioning: Design at the Early Stage, Integral Publishing, Sydney Parlour, R.P., 1994, Building Services: Egineering for Architects, Integral Publishing, Sydney Schevers, H., Tolman F.P., 2001, “Modelling the first building life cycle stages”, in Proceedings of the CIB W78 conference, White River, Mpulanga, South Africa Stein, B., 1997, Building Technology: Mechanical & Electrical Systems, 2nd Edition, John Wiley & Sons Stein, B. & Reynolds, J.S., 2000, Mechanical and Electrical Equipment for Buildings, 9th Edition, John Wiley & Sons Tucker S.N., Ambrose M.D., Johnston D.R., Newton P.W., Seo S. and Jones D.G., 2003, LCADesign: An integrated approach to automatic eco-efficiency assessment of commercial buildings, Proc CIB W78, Auckland van Leeuwen, J.P. and R.H.M. van Zutphen, 1994, Architectural Product Modelling—a Case Study. In: Proceedings of the CIB W78 Workshop, Helsinki, August 1994

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

State of the art of the implementation of Information Management Systems in the construction industry in Spain N., Forcada, M.Casals & X., Roca Universitat Politecnica de Catalunya, Barcelona, Spain ABSTRACT: From all over Europe, many improvements in terms of Information and Communication Systems have been implemented. In the construction sector, large enterprises use Information Systems to manage internal documents to control their ever-increasing number of various documents and drawings. Many companies use Information Systems to standardise the way information is for anybody with correct privileges to find and access the document they want. An Information System helps the user perform their work easier and provides the company with security, data reliability and work process management. Many of these features eventually save time, simplify work, protect investment made in creating these documents, enforce quality standards, enable an audit trail and ensure accountability. Although most technical aspects of Information Systems are resolved by the adoption of low cost databases and easier integration with the Windows environment, companies often resist to implement changes in their organisations because of the costs and complexity involved in implementing Information Systems. Moreover, in Spain the change in working culture and practices, which is required initially, very often deters the users. In this Paper we will show the State of the Art of the implementation of Information Management Systems in the construction Industry in Spain. We will also expose how the Spanish building sector is facing Interoperability and Information Systems and also and schema of a strategy and implementation plan, a training programme to develop, and the definition of operating procedures to modifying organisational structures, to extend the use of Information Management Systems.

1 INTRODUCTION Nowadays, the handling of information and its access has been converted into essential factors for the economical development and business success. In the last years, Information Society and basically Internet, has become the main information transmission and communication media among companies.

Ework and ebusiness in architecture, engineering and construction

732

Probably, the construction industry is the geographically most dispersed and it involves a big quantity of Small and Medium Enterprises. The variety of professionals in a project can easily cover dozens of disciplines from architecture, engineering to installations and demolition, all with very different information requisites. In this paper we will analyse the current Systems and on-line platforms that are being used for the construction industry in Spain to improve Project Management. From the beginning of Internet (early 90s) these services have changed significantly. First, only static information was provided on the web. The evolution tended to join professional users’ communities and create a dynamic space to exchange and share information and currently researches and investigation is being focused on collaboration. 2 WEB BASED PROJECT MANAGEMENT TOOLS FOR THE CONSTRUCTION SECTOR The Construction Sector and specifically AEC industry is one of the most challenging for Project Management. For any given project, many different participants from many diiferent professions, often widely dispersed geographically, are thrown together for a limited duration. Team collaboration and information exchange is absolutely critical yet. It is believed that the use of Web-based Project Management tools will have as substantial impact on the design, construction and operation of buildings, plants and infrastructure projects. The sheer number of parties that require coordination to bring a project to completion is a challenge. In order to do so, the industry has relied on traditional communication methods, typically time and labour

Figure 1. Traditional chaos in the communication and workflow of AEC industry.

State of the art of the implementation of Information Management Systems

733

intensive that have resulted in higher costs and inefficiencies (Figure 1). Coordinating the numerous parties involved to take a project from initiation through construction is often a daunting experience. Owners/developers, architects, engineers, general contractors, specialty contractors, material suppliers and government and regulatory bodies have all traditionally communicated using methods such as fax, face-toface meetings, email, couriers and mail to exchange ideas, provide progress updates, schedule labour, deliver documents and make supply requests. The complex process required to turn around a RFI (request for information) illustrates some of these inefficiencies: today, a RFI is hand-written by a specialty contractor, faxed to the general contractor, reviewed/rewritten and faxed to the architect. The architect may fax it to a sub-consultant (electrical, structural, mechanical) for review, who in turn may fax it to a sub-sub-consultant (lighting, acoustical) for input. The response is formulated, documented and sent back to the sub-consultant for review, and then faxed back to the architect. Assuming no further clarification is needed, the architect faxes the RFI back to the general contractor and the owner. Once approved by the owner, the RFI is faxed back to the specialty contractor with action items. Finally, the general contractor needs to ensure that the response is received on the job site by foremen, staff, specialty contractors, suppliers, project managers and administrators, all in their respective office locations. As the above example demonstrates, we believe the AEC industry is ready to take advantage of current developments in online project collaboration tools. Incorporating these tools into current industry practices can make a significant difference. Collaboration software enables organisations to centralise electronic documents, thus allowing users from a number of different organisations to work in a more collaborative fashion. The primary objective is to move away from traditional sequential paper-based systems, thereby breaking down barriers to communication. In the construction industry, there are typically 50 to 250 organisations involved with the execution of building contracts, (construction professionals, contractors, specialist contractors, suppliers, statutory authorities, health and safety, highways agencies etc.). Traditional paper based administrative systems mean that for every document issued, there is need to copy (sometimes in part, sometimes whole) and pass “down” the supply chain sometimes for information, sometimes for comment and return and usually in accordance with some level of contractual obligation. Bearing in mind the number of organisations in a typical project supply chain, this creates two major problems: – the system is inherently challenging in terms of effective communication and – the administrative burden is tedious and expensive. Ineffective communication and poor administration lead to bad management. The essence of collaboration software is to develop a process whereby documents are all electronic, thus enabling them to be located at a secure central location that can be accessed by those to whom access rights have been given while maintaining business processes, supply chain relationships and organisational hierarchies. In Figure 2 both situations, traditional project management and web based project management are shown. The basic improvement is the centralisation of the information as it can be noticed.

Ework and ebusiness in architecture, engineering and construction

734

Project collaboration services focus on tools and services that make it easier to manage the AEC (Architecture, Engineering and Construction) design projects. Common services include backing up files, keeping a document revision history and tracking who accesses what files. Such sites also offer online document viewing, online markup, and plotting. Three main services are available in Web Based Project Management Systems: Business Process Automation, Online Document Management andTeam Communication. Many other services are also available but they can be grouped in one of these three main services. On line project management provides an instant, on-demand, secure online solution for all team members to communicate, share documents and collaborate using a standard Web browser. The heart of some on line project management systems is a secure document management and workflow system that stores all project documents and forms. The information repository can be updated daily to ensure that everyone has access to current information. It enables everyone in the project team to work from the same page, improving productivity. It helps accelerate time-to-market, reduce cost, increase revenues and to minimized rework due to communications errors. With a minimal investment in Internet technology and personnel, On line project management systems provides the tools for instant information access anytime, anywhere as it can be noticed in the following Figure, collaborative software offers any kind of information services (consult, procure, maintain, modify, etc.). Throughout the lifecycle of the project.

Figure 2. Communication mechanisms between enterprises.

State of the art of the implementation of Information Management Systems

735

Figure 3. Information services of collaboration software throughout the lifecycle of a project. Online project management is an out-sourced Internet-based project information and workflow management service for the design, engineering and construction industry. It provides specialized tools for all the individuals involved in the building process and enables construction projects to be completed under budget and ahead of schedule. This service is focused on providing prqject teams with rapid, secure, and easy access to project information. It promotes the concept of “partnering”—enabling project owners, planners and architects to collaborate and to jointly determine how best to fulfil the goals of the project. To implement effective partnering it is critical that all project players remain in regular contact with each other and have access to the same data. To insure effective coordination of the numerous partners that make up the project team, it is critical to get everyone communicating as quickly and efficiently as possible. 2.1 Advantages of the Web Based Project Management The adoption and benefits gained in using online project collaboration tools within the AEC industry has been studied by PricewaterhouseCoopers LLP and has found a number of very real and tangible benefits currently being experienced by early adopters (Wesek J. et al, 2002). In this study, it’s said that overall the use of these tools within the industry is in its infancy, with architects, engineers and general contractors leading the way. Owners, developers and specialty contractors currently seem to be slower in their adoption, in part due to limited exposure to the use of these tools and infrastructure issues. They believe that the benefits currently being realized by early adopters cover only a limited range of the services that can potentially be offered by online project collaboration tools; today these benefits centre around:

Ework and ebusiness in architecture, engineering and construction

736

– Improving project progress communication, – Providing access to information and reducing the response time for RFI (Requests for Information), – CO (Change Orders) and specifications clarification, – Shortening of the project life cycle, – Increasing ownership and accountability, – Improving record keeping and documentation. These benefits have far-reaching implications for construction projects. By improving prqject progress communication, all team members are kept informed of issues in a timely manner, project schedules are distributed faster, and consequently, less overlapping and/or no show of workers would occur. If the cycle-time taken to turn around a RFI/CO is shortened, this could have a direct impact on the length of the project: with fewer delays and quicker response times, the life cycle of a project can be shortened. Shortening the life cycle of construction brings benefits such as reduced expenditures in man-hours, equipment rentals, project site office costs, and security costs and allows the project team to begin working on new revenue-generating projects. Finally, by completing the project sooner, tenants can occupy the site earlier and owners/developers can enjoy earlier rental/lease revenue. As the AEC industry moves to embrace these tools, all participants will realize additional benefits progressively. It’s foreseen that as understanding of client needs and adoption increases, vendors will develop product offerings to meet the needs of all industry players; in turn, these will increase overall usage of online project collaboration tools. It’s believed that the AEC industry will open itself up and adopt the changes brought about by the development of online collaboration tools. Finally, in the not too distant future, it’s believed that online collaboration tools will be able to extend their offering to not only enable project collaboration but also support procurement and market capabilities (i.e. matching buyers and sellers). 2.2 Utilization of Web Based Project Management tools in the construction industry The AEC industry is in the early days of adopting these online collaboration tools; however, early adopters are already realizing some of the benefits to be gained. In general, architects, engineers and general contractors are adopting online project collaboration tools and understand the benefits to be gained. Specialty contractors were the least likely users of online tools and owners and developers, although keen to try this technology, were hesitant to adopt it at this stage. Further reasons for the adoption and non-adoption of onlinetools are: – Architects and engineers are most likely to use online project collaboration tools as they: have the infrastructure necessary to support them (i.e. network systems, hardware, etc.); have technologically savvy employees familiar with technological solutions such as computer-aided design (CAD) – General contractors are also keen adopters of these tools; some of the reasons are that they: have seen some of the associated benefits through demonstrations and marketing

State of the art of the implementation of Information Management Systems

737

efforts; have been mandated to utilize a specific tool by an owner/ developer or architect felt much of the communication frustrations and could foresee that these tool would help alleviate this burden; have the infrastructure necessary to support the tools (i.e. network systems, hardware, etc.) – Owners and developers had mixed responses regarding the adoption of online tools. Some were early adopters where as others were not. Reasons for their positions include: adoption driven by marketing and advertising campaigns; resistance attributed to lack of critical mass of players within the industry currently using the tools – Specialty contractors have to date been the most resistant to adopting these tools. Those using them were doing so because they: have been approached to be part of a project team which was using a particular tool; have seen advertising/marketing efforts; believed that this was the way work is to evolve in the future. Collectively, reasons for resistance cantered on the lack of exposure and education about these tools within the industry. As evidenced from the research, the drivers to adoption in the AEC industry are less about understanding the benefits and more about perceived benefits, client recommendation and awareness brought on by marketing campaigns. 2.3 Study of different collaborative extranets After analysing all the Web Based Project Management services that are currently available for the construction sector, two of them have been studied in depth by means of interviews with their managers. From one side, ProjectCentre from Bricsnet was chosen because it’s one of the few Web Based Project Management services that have headquarters in Spain and the software is available in Spanish. The other one was ProjectNet from Bidcom. It was also studied because the ProjectNet Extranet Solution is one of the global leaders in collaboration. In this case Bidcom is from UK and for the moment it’s services are still not available in Spain. 2.3.1 ProjectCenter In April 2001, Bricsnet presented the first on-line construction Project Management solution in Spanish: ProjectCenter. This platform was orientated towards promoters, owners, construction companies, public administrations and engineering companies for the management of projects through Internet. This tool enables all users previously authorised, to have access to all the documentations of the project. A 20% of the projects in UK have already used extranets in 2001. Promoters leader this market as it can be seen in the next figure. A 32% of the companies with more than 100 workers have already used an ASP service for the management of collaborative projects. In Spain, promoters (35%) and engineers (23%) are the main users of these kina of new technologies for the management of construction projects. See Figure 5.

Ework and ebusiness in architecture, engineering and construction

Figure 4. Evolution of the market in Great Britain.

Figure 5. Implementation of ProjectCenter in Spain by type of companies.

Figure 6. Localization of projects using ProjectCenter in

Spain.

738

State of the art of the implementation of Information Management Systems

739

By autonomic communities, Madrid, Catalonia and Andalucia are the regions that use more these kind of tools. 2.3.2 ProjectNet Bidcom Ltd is the leading provider of online collaboration solutions for the design, engineering and construction industry. Bidcom Ltd, based in London, provides sales and service solutions throughout Europe. Originally founded in 2000, Bidcom Ltd has developed lasting relationships with some of the world’s leading companies, including owners, architects, engineering and construction firms. Bidcom has developed a very powerful tool for the management of on-line projects in construction, ProjectNet. ProjectNet is a way for all team members to share and access project documents around the clock and around the world. ProjectNet is powerful and scalable, and includes project management tools such as RFI’s, Submitted Samples, Architect’s Instructions, Meeting Minutes, Action Items, Logs, and more. ProjectNet is the glue that brings all of the disparate systems from multiple organisations together in one environment, the web. Some of the key features of ProjectNet are: Automatic file conversion for browser viewing of all file formats; Folder creation and access control by multiple users. For example, both the architect and the contractor can create folders that the other cannot see. Individual users or groups can be given rights to create subfolders under one folder without giving them the right to create folders everywhere; External Reference file management for AutoCAD, Microstation and Primavera. All Xrefs are automatically uploaded and downloaded. If you upload 100 DWG’s all pointing to the same Xref, the Xref is only uploaded once; a user or group can have multiple workflow roles. For example: the contractor may only be allowed to submit RFI’s to the Architect; and the Architect can only submit RFI’s to the Owner’s rep.; Workflow (RFFs, Meeting minutes, Submittals, etc.) items can link to multiple documents previously uploaded; and automatically create calendar and task items. ProjectNet has over 6.000 active users in the UK. Bidcom’s customers include facility owners and operators, architecture, engineering and construction firms. After analysing these services, we reach the conclusion that the majority of Web Based Project Management Services are addressed to Architecture and Engineering Studies, Contractors and Owners. All the other participants like suppliers; quality control entities, etc. usually use these services not for the management of the project but for consulting. This means that they will have certain accesses and privileges but they won’t be the direct users. Basically, Web Based Project Management services are only focused on document management and communication management, other services like electronic transactions are not offered in these services. They are very complex and specific tools. Because of this, we have analysed and studied some architecture and engineering studies, contractors and owners who are working with some kind of Web Based Project Management services. The aim was to have a general view of the application of these services. It must be said that we have chosen solid companies with a high degree of innovation. This means

Ework and ebusiness in architecture, engineering and construction

740

that this analysis is not to reach conclusions on the use of these tools in SMEs of the construction sector. The majority of AEC SMEs in Spain don’t use any kind of Management System and sometimes neither PCs for their day-to-day work. 2.4 Study of some companies using Web Based Project Management services 2.4.1 JG Asociados As a representative for the role of designer in the construction Project (Architect, Engineer, etc.) we have chosen the engineering company JG Asociados. Although JG Asociados has a Web Based Project Management tool called COBRA, it’s an internal service for the organisation of the company’s information. It has three servers: one for Internet and e-mail, another for projects that is divided by delegations and the last one is for models and software. The server also stores all the particular information of all the workers of the office in a space called Users. The Web Based Project Management COBRA is divided by areas: projects, bids, time and cost, general data, turnover, consultations, accounting and payments. The project area allows generating new projects or edit the old ones. The nomenclature to define a project is characterized for an initial depending on the delegation, 3 correlative digits and the starting year of the project. For example the project B00103 is the first project from Barcelona’s delegation of 2003 year. Each project includes the options of Payments, General Data, Attributes (class, type, surface, budget), Contacts (architect, acoustic consultor, promoter, etc.) Prevision (person, hours, etc.), Images, Results (comparison between the expected results and the real ones to do a balance of the project), Web link. All JG Asociados workers have access to incorporate their personal data like the hours they invest in a project but other information like biddings, contact persons, etc. are restricted to some persons. The bidding area allows creating new offers or consulting the state of the offers. Other options are the management of hours and costs, introduction and control of the collaborator’s hours and costs. Relating to general data, information like contacts, collaboration data, Cobra help, etc. is available and can be edited. In the turnover area, the allowed people can insert, control and consult the turnover. There is also an area of general people consults (working charges of a current project, costs, etc.) bids (total, accepted, etc.) costs graphs, hours, etc. Another functionality is the accounting and payments that includes consults of companies and delegations. As a conclusion, COBRA is basically a human resources and project accounting control and management systems, a system that allows the classification of the basic information of the projects in each delegation. It works as an Intranet but some areas of information can be viewed on the web, so it works partially as an Extranet. Moreover, they are working in some projects that they were required by the client to use some collaboration platform.

State of the art of the implementation of Information Management Systems

741

2.4.2 IDOM Idom Architecture, Engineering and Consulting opted for creating their own Web Based Project Management System focused on the specific characteristics of their projects. With this application they aimed to solidify the digital management of the company activities processes reducing drastically the paper based storage of information, to facilitate the exchange of information (easy, faster and cheaper) and to improve their working methodology. The tool is structured as a Lotus Notes (.nsf) database stored in a server of the company and published in Internet (D.Prosper et al, 2002). When developing the tool they opted for a simple and friendly (loolk & feel) application to guarantee a fast access to the information. From IDOM a very relevant aspect of having the information in digital support was the easiness of finding information in a multidimensional classification. They have chosen three ways of document classification: firstly, a Decimal Classification due to the way they organise paper based documentation, secondly, a classification for types of documents, sometimes more useful for certain external collaborative spaces, and the third option by keywords. In all cases, the responsible of the project can chose the classification that fits better to the object and participants. Each agent that takes part of the project has the information that has stored previously available, the information that other agents have put at the disposal of them and a tool to store information. The document publications between agents can be enclosed by an email message. They basically store document in .pdf format. When a document comes from different applications (text, images, excel, etc.) the .pdf format helps the readness of the document. The only problem is that it’s never editable. When publishing a document, the person who publishes it should specify to who is addressed so as he or they will be the only people who will visualize it and because of a major control of the information, major flexibility and trying not to charge agents with superfluous information. The management of biddings is also done via Internet. According to IDOM this application has been successfully accepted in the company. By the end of 2002, more than 200 projects were using it. The experience created some problems that can be summed up in: – The digital management of a project is not easily assumed by all the involved agents. In general terms, the tnost effective way would be the obligation at contractual level by the Client to use these tools. But, although a Web Based Project Management tool were imposed, certain suppliers will have limitations for not having and adequate technical infrastructure. – The digital edition of documents like a letter is easy to implement. But, certain type of reports or the technical documentation of the project with a complex structure, need a complementary paper based edition. – Digital management won’t avoid paper based communication and documents of specific characteristics. Normally a notice is given by letter, projects are “visados” in paper, etc. But it is also a fact that interesting experiences are beginning like electronic visado, digital signature, etc.

Ework and ebusiness in architecture, engineering and construction

742

– When the information project is stored in the server of a partner company, the other agents can doubt of the manipulation of the information. In this sense, the acceptance of the electronic signature can be used as a validation element to increase the trust. The development of this tool was initially for the management of internal aspect, but for IDOM it can be very useful for external agents. To improve this factor, they want to: – Provide specific formats for some type of documents like reports, minutes reports, etc. – Create an option to visualize documents. Currently there is only the possibility to open documents with the programmes that are installed in the PC. – Create a fast and informal communication modality, like chat, incorporating and agenda for the control of the development of activities. – Currently, the tool develops functions as a repository of information. In a near future, they want to incorporate collaboration tools to allow a common generation of documents. 2.4.3 Fomento de Construcciones y Contratas (FCC) At the beginning of 2001, FCC created an Intranet for the management of the company. The solution was a private IP net with the following services: e-mail, web publication, documents transfer, net remote management, corporative database and Internet access. Referring to the e-mail, they have a global addresses list, which is a public archive system, controlled by electronic permissions and forms. The web publication is formed by a Technical Boletin, Topics of Informatics (relation of applications, specifications and equipment costs, reports and manuals), Training (indexes and texts of the internal courses), Quality and Environment (agreements of the Quality Committee, General Procedures, experiences to transmit, improvement equipment), Machinery (internal norms and machinery utilization, norms for the risks prevention, etc.), Spain Constmction (list of current sites). Referring to document transfer, the Intranet includes documents of the Quality System, Drivers and Controllers and software installations. From the net remote management, remote login, net monitoring, inventory and hardware management can be obtained. In relation to the corporative database, biddings, catalogs of suppliers and photographs of different sites are stored. The tool also allows Internet access and access to public databases. Concluding, and based on the study carried out by FCC and presented in the seminar ConstruTIC (FCC, 2001) the implantation of the Intranet obtained: faster and better fiability of the information distribution, fluidity of the communication between Central Services and Sites, quality of the information, awareness of the advance grade of the sites. 2.4.4 GISA GISA as a reference of the construction sector in Catalonia is leading, together with Accenture, the development of a Collaborative portal based on a unique data repository, accessible via Internet (GISA, 2002). This portals allows to deliver documentation to

State of the art of the implementation of Information Management Systems

743

Gisa through the portal, in a agile and structured way, to publish monthly reviews and the advance of the site, to identify the different actors that are in each stage of the project participating on it and to make easy the communication between them. After some time using this collaborative portal the following results are extracted: In reference to the usability of the system and based on the improvements suggested by the users, the number of folders and levels should be reduced to a maximum of two and it’s necessary to define document forms where the nomenclature and the document structure to publish were established. Site directors valuate positively the save of time, and both internal and external workers consider the system very useful to add value to their diary tasks. In a near future they foresee integrated the digital signature. 3 CONCLUSIONS Concluding, some companies have leaded the application and development of Web Based Project Management System, creating their own platforms. However, the majority of SMEs don’t use any kind of Web Based tool, even they don’t have web page or don’t use PCs for their current work. Taking into account that the tendency of the sector turns to the use of these management tools, these SMEs will be forced to start using them. Nevertheless, big and some of medium companies are investing in creating their own Intranets for the Management of their business and in a near future these tools will be used as collaborative spaces with other partners of the project. The main problem will be the differences between these services. Each company is adapting these services to their necessities and obviously, each company has different organizational and ftinctional systems. It’s therefore, necessary a common organisational modeltounifyalltheavailablesystems. REFERENCES Wesek J., Cottrez V., Landler, P. (2002), A Benefits Analysis of Online Project Collaboration Tools within the Architecture, Engineering and Construction Industry. Price Waterhouse Coopers Prosper, D., Rey A., San Emeterio, I. 2002. Experiencias en el desarrollo y utilización de una herramienta extranet de archivo y comunicación en la gestion de proyectos de construcción. VI International congress on Project Engineering, Barcelona, pp 160 GISA, 2002, Área Col.laborativa per a la gestió de Direccions d’Obres. Jornada sobre Posibilidades de Internet en el Sector de la Construccion. Barcelona 26 de Junio de 2002. FCC’ 2001, Seminario sobre las tecnologías de la información y comumcación a la construcción. ConstruTIC. eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork A.Gehre, P.Katranuschkov & R.J.Scherer Institute of Construction Informatics, Technical University of Dresden, Germany ABSTRACT: This paper presents an extensible dynamic distributed ICT infrastructure for cross-company teamwork in virtual organisations which allows to set up easily and user-friendly team-oriented information spaces assembled ad-hoc from different information sources, such as dedicated project servers, corporate information systems, content service providers, and last but not least the workstations of the users themselves. The suggested approach combines the technologies and methods of Peer-ToPeer based distributed networking, autonomous software agents and ontology-centred management of information resources. After a short introduction, background and related work are discussed. The main chapter of the paper details the specific objectives and the approach of the hybrid agent-enabled Peer-To-Peer infrastructure, and provides insights to the three conceptual layers applied, namely the PeerTo-Peer layer, the agent layer and the ontology layer. A specific section is dedicated to the realisation of a first demonstrator validating the approach. The paper is concluded with an outline of envisaged further research steps and conclusions drawn from the work performed so far.

1 INTRODUCTION Efficient provision and management of information are key requirements for planning processes in the construction industry. Building construction and management demand a coherent information management considering the multitude of companies and stakeholders involved as well as the broad variety of electronic infrastructure and standalone information management systems deployed. The current state of the art in project centred information management in AEC/FM is still represented by web based extranet platforms. However, being mainly based on the client-server paradigm and used over the internet these systems do not adequately address the information management requirements. They require a homogeneous organisational and software structure that cannot be automatically assumed for teams assembled from participants of different companies and for one single project or even for a part of a project. Moreover, the time-consuming explicit management of information performed manually (check-in, check-out, etc.), expenses for renting the portals, and the difficulties in integrating the platforms with internal electronic infrastructure are crucial aspects. The objective of the research work presented in this paper is the realisation of an extensible dynamic distributed ICT infrastructure for cross-company teamwork in virtual organisations dealing with one-of-a-kind products, processes and events. This

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

745

infrastructure should allow to set up easily and user-friendly team-oriented information spaces, assembled ad-hoc from different information sources, such as dedicated project servers, corporate information systems, content service providers, and last but not least the premier participant, the machines of the different users itself, as depicted in Figure 1. This approach should (1) bring together physically divided information resources and users, (2) provide an efficient medium for ad hoc generation and sharing of

Figure 1. Building team-oriented information spaces, assembled ad-hoc from distributed information sources. content, and (3) enable flexible team-oriented information exchange and management. In order to meet these objectives an infrastructure is being developed that combines the technologies and methods of P2P based distributed networking, autonomous intelligent software agents and ontology centred management of information resources. The current state of development described in the following concentrates on the agentenabled P2P network infrastructure, whereas the information management ontology framework is presently under design and only roughly described. 2 BACKGROUND AND RELATED WORK Numerous approaches and systems have been explored for information management in dynamic heterogeneous distributed environments, most of them utilising Multi Agent System technology and P2P concepts, in some cases enriched with a domain model captured within an ontology on a meta-information layer. In the following subsection the most important features of the three technologies are introduced. However, as comprehensive technological explanations are beyond the scope of the paper for more comprehensive discussions on these technologies the reader is referred to (Ferber 1999)

Ework and ebusiness in architecture, engineering and construction

746

and (Jennings & Wooldridge 1998) for an elaborated introduction to Multi Agent Systems, to (Milojicic et al 2002) to gain an insight into P2P computing and to (Guarino 1996) for a short familiarizing with the ontology concept. In Multi Agent Systems (MAS) specialised agents representing the users, the information resources, and the system itself cooperate to address the information processing requirements of the users, allowing for easy, dynamic reconfiguration of the system and its resources. The key aspect of software agent technology is autonomy, which allows the agent to decouple the sequence of operations from the user interactions. The use of agent technology provides a high degree of decentralisation of capabilities which is the key to system scalability and extensibility (Bayardo et al. 1997). The P2P communication model allows PCs and other computational entities, connected in a network, to communicate or share computational tasks and resources without the explicit need for a server (as in web-based models). Each node is equal (peer) to all others, and may operate as router, client, or server according to the task to be performed. In addition, some protocols (e.g. Napster, Gnutella) use message routing mechanisms based on broadcasting and ‘time to live’ marker techniques. However, pure P2P based tools have fundamental limitations, such as limited expressiveness of messages (languages can only talk about objects/data that are well defined and uniquely identified by their names, e.g. MP3 files, images, etc.) and rather simple data models covering mainly file directories (Panti et al 2002). The power of P2P systems emerges from their remarkable efficiency in self organising robust dynamic systems of independent peers at runtime, enriched with advanced capabilities of modern P2P frameworks, as e.g. JXTA (Sun Microsystems 2003), like peer-grouping and elaborated security for communication channels. This is where almost all modern agent frameworks provide pretty poor performance, although they are internally based on the P2P communication model too. Ontologies as domain models can provide for a concise, uniform, and declarative description of semantic information, independent of the underlying syntactic representation or the conceptual models of information bases. Domain models widen the accessibility of information by allowing the use of multiple ontologies belonging to diverse user groups (Bayardo et al 1997). Several projects have combined two or three of these essential concepts. Most prototyped systems apply the advanced Multi Agent System approach for intelligent distributed information and knowledge management, e.g. the projects CoMMA (CoMMA Consortium 2000), InfoSleuth (Bayardo et al 1997), and MAP (Weiss et al 2003), the later emphasizes the mobility of the user and his/her devices. These projects utilise the standard P2P functionality of MAS frameworks for establishing their own distributed networks. However, these projects lack an advanced methodology for building robust dynamically changing distributed networks, in particular in an ad hoc manner. All MAS based systems deploy their own proprietary ontology to leverage inter-agent communication and information exchange. Some of them (cf. e.g. CoMMA), provide ontology inference mechanisms enabling automatic derivation of new information/ knowledge about information resources. Whereas projects five years ago developed their ontologies more or less from scratch, the majority of present approaches revert to available ontology standards, such as the Resource Description Framework (RDF) (W3C

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

747

2004a), as well as DAML+OIL (W3C 2001) and OWL (W3C 2004b) as more appropriate specialisations of RDF. The potential of a powerful semantic web framework harnessing P2P technology was demonstrated in the SWAP project (Ehrig et al 2003). Unfortunately, this project did not realise the potential that agent technology could contribute to the SWAP framework. 3 HYBRID AGENT-ENABLED PEER-TO-PEER INFRASTRUCTURE 3.1 Speciflc development objectives The general objectives mentioned in the introductory chapter can be broken down to more specific design

Figure 2. Establishing virtual prqject spaces in a dynamic flat network topology using virtual mapping to physical networks.

Ework and ebusiness in architecture, engineering and construction

748

requirements regarding the infrastructure to be developed. 1 Decentralisation and facilitation of the complex information management process by shifting the management responsibility from server(s) to the clients that are now individual peers with equal rights, as depicted schematically in Figure 2 below. 2 Enabling establishment of coherent virtual project spaces by integrating the autarchic heterogeneous information subsystems of the projectparticipants. The infrastructure has to enable the users to dynamically switch among different project spaces as well as to initiate thematic subspaces on his/her personal responsibility. 3 Harnessing software agent technology in order to (1) delegate as much as possible manual information management tasks (incl. notification services) from users to agents supervised by the user; (2) facilitate search for document and information resources based on information gathering agents, utilizing a resource ontology and methods from artificial intelligence; and (3) provide an intelligent and user-friendly interface to the system by employing a software agent as mediator utilising the domain specific resource ontology for interface purposes. 3.2 Approach Having in mind the potential of MAS, P2P and ontologies, the first question to answer is: How can these concepts be merged within a coherent, efficient and robust system for challenging advanced provision, search, exchange and management of information in dynamic heterogeneous distributed environments?

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

749

Figure 3. Layered software architecture integrating Peer-To-Peer networking and software agent technology. The presented technological approach combines the P2P framework JXTA (Sun Microsystems 2003) and the JADE (Java Agent Development Framework) MAS framework (Rimassa 2003) and facilitates the systematic exploitation of their respective capabilities and advantages. The P2P layer establishes a dynamic ‘flat’ network topology ensuring the overall technical interoperability and the basic information and resource management. The agent technology layer leverages the underlying P2P functionality to provide advanced features such as intelligent automated processing of various knowledge-intensive and/or contextdependent tasks, automated information gathering, as well as enhanced discovery and notification services.

Ework and ebusiness in architecture, engineering and construction

750

The five principle technological layers, depicted in Figure 3, demonstrate an increasing abstraction of applied software concepts from bottom to top. The three bottom layers are build by the P2P framework JXTA, developed by Sun Microsystems. They are characterised as follows (Sun Microsystems 2003): – The JXTA core layer encapsulates the minimal and essential primitives that are common to P2P networking. It includes building blocks to enable key mechanisms for P2P applications, including discovery, transport (including firewall handling), the creation of peers and peer groups, and associated security primitives. – The services layer includes network services that may not be absolutely necessary for a P2P network to operate, but are common or desirable in the P2P environment. Examples of network services include searching and indexing, directory, storage systems, file sharing, distributed file systems, resource aggregation and renting, protocol translation, authentication and PKI (Public Key Infrastructure) services. – The (P2P) applications layer includes implementation of integrated applications, such as P2P instant messaging, document and resource sharing, entertainment content management and delivery, P2P E-mail systems, distributed auction systems, and many others. These three P2P layers provide the infrastructure background for the two upper agent technology layers, established by utilizing the JADE agent development framework. – The agent infrastructure services layer provides all necessary service agents for keeping the MAS running. According to (Rimassa 2003) the two most important ones are: (1) the Agent Management System (AMS) that exerts supervisory control over access to and use of the underlying (P2P) platform; it is responsible for maintaining a directory of resident agents and for handling their life cycle, (2) the Directory Facilitator (DF) is the agent that passes on yellow page services to the agent platform, and finally (3) an Interface Agent (IA) managing the inter-platform communication through the P2P layer, as described below. – The most interesting layer for the system itself and the users is the applications layer which shelters the specific application agents characterising the platform. Agents residing on this conceptual layer are e.g. information gathering agents, the user interface agent, acting as the mediator between the system and the user, or agents performing the enhanced resource management and supporting the dynamic distributed collaboration. Having in mind the powerful services provided by the three bottom P2P infrastructure layers it is obvious that the agent platform itself is freed from a lot of basic system management work and additionally can revert to advanced and robust P2P concepts e.g. dynamic distributed resource sharing, peer-groups and the Super-Peer networking model for bridging peers that do not have direct physical connectivity (NAT, firewalls). In this way a secure, reliable and scalable information infrastructure enabling teamwork-driven just-in-time collaboration and flexible sharing of information, as well as computational and human resources can be achieved. The two information technology layers (P2P and MAS) as well as the foreseen ontology layer will be explained in more detail, in the following subsections.

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

751

3.3 The Peer-To-Peer layer The bottom three technological layers (see Figure) establish a P2P network based on the JXTA development framework. This has several consequences regarding the communication model that is quite different from Client/Server systems. The key concepts of this decentralised model are outlined in the following, according to (Sun Microsystems 2003). The JXTA network consists of a series of interconnected nodes, or peers. A peer is any networked device that implements one or more of the JXTA protocols. Peers can include sensors, phones and PDAs, as well as PCs, servers, and supercomputers. Each peer operates independently and asynchronous from all other peers, and is uniquely identified by a Peer ID. Peers are not required to have direct point-to-point network connections between themselves. Intermediary peers may be used to route messages to peers that are separated due to physical network connections or network configuration (e.g. NATs, proxies, firewalls). Peers are typically configured to spontaneously discover each other on the network to form transient or persistent relationships called peer groups. The peers self-organise into peer groups, each identified by a unique peer group ID. Each peer group can establish its own membership policy from open (anybody can join) to highly secure and protected (sufficient credentials are required to join). Peers may belong to more than one peer group simultaneously. Groups also form a hierarchical parent-child relationship, in which each group has a single parent. Search requests are propagated within the group. A peer group provides a set of services called peer group services. In order for two peers to interact via a service, they must both be part of the same peer group. The core peer group services include Discovery Service, Membership Service, Access Service, Pipe Service, Resolver Service and Monitoring Service. For more details about these services see (Sun Microsystems 2003). The peers use pipes to send messages to one another. Pipes are asynchronous and unidirectional message transfer mechanisms used for service communication. Pipes are indiscriminate, i.e. they support the transfer of any object, including binary code, data strings, and e.g. Java technology-based objects. Pipes are virtual communication channels and may connect peers that do not have a direct physical link. In this case, one or more intermediary peer endpoints are used to relay messages between the two pipe endpoints. Pipes offer two modes of communication, point-to-point and propagate. Furthermore, the JXTA core also provides secure unicast pipes, a secure variant of point-to-point pipes. The basic unit of data exchange between peers are messages. A JXTA message is an ordered sequence of named and typed content called message elements. Thus a message is essentially a set of name/value pairs. The content can be of arbitrary type. On the presented hybrid platform the multitude of relevant messages transported by the P2P layer are wrapped ACL (agent communication language) messages, handled by the interface agents residing on the agent technology layer, as described in the subsequent chapter. All network resources, such as peers, peer groups, pipes, and services, are represented by an advertisement. Advertisements are language-neutral metadata structures in the P2P network, represented as XML documents. The JXTA protocols use advertisements to describe and publish the existence of a peer resource. Peers discover resources by searching for their corresponding advertisements, and may cache any discovered advertisements locally. Each advertisement is published with a lifetime that specifies the

Ework and ebusiness in architecture, engineering and construction

752

availability of its associated resource. Lifetimes enable the deletion of obsolete resources without requiring any centralised control, what is an essential feature for the developed distributed platform. An advertisement can be republished (before the original one expires) to extend the lifetime of a resource. For the sake of not going beyond the scope of the paper, security issues concerning the transport layer security are omitted here. The interested reader is referred to (Sun Microsystems 2001) which outlines the trustworthy security mechanisms JXTA comes with. 3.4 The agent layer After the principle discussion of the P2P layer communication model, this section describes how the agent technology layer facilitates that functionality in order to establish the MAS hosting the advanced application agents. Establishing a MAS utilizing a pure JADE platform is performed by running a main agent container hosting the AMS and the DF, and subsequently starting optional agent containers on the same or other machines. The crucial aspect is that this architecture is more or less comparable to a Client/Server architecture with the main container acting as the central server-like instance. If the main-container disappears, the agent platform runs out of service. Moreover, a permanent network connection between the main container and its sub-containers is essential. This JADE basic principle is not compatible with the intended P2P-based distributed architecture, where peers dynamically build groups and are free to join and leave the network as they want. Therefore, the basic JADE architecture had to be broken down into distributed single JADE platforms, each with its own main container, only connected by the underlying P2P infrastructure, as shown in Figure 4. Although this approach seems quite simple, it entails several consequences. The most apparent consequence is that now every peer has to run a main container with an AMS and a

Figure 4. Braking down the centralized JADE architecture ensuring a real P2P environment

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

753

DF. Therefore more resources are required on all participating machines. Furthermore, one agent technology feature commonly considered as very important, the agent mobility, is lost. In JADE agent mobility is only supported within a closed platform. This means that software agents can only travel among the participating containers of the platform environment. However, for the developed hybrid agentenabled P2P infrastructure this drawback is justifiable as the main operational area for mobile agents is the distributed information search and collection; a feature that is heavily supported by the P2P-connected stationary agents in the presented infrastructure. Moreover, it seems that currently there are efforts running in the JADE community to upgrade JADE with inter-platform agent mobility. Hence, eventually this feature will be integrated within some next version if it is really needed by a future extending application. The most tricky consequence of braking down the single agent platform comes with the inter-agent communication. The message routing in the JADE MAS is entirely performed by the platform; to send a message the agents only have to know the name of the receiver. The platform automatically delivers the messages within the platform. For inter-platform message delivery, additionally the name of the targeted platform and its Interoperable Object Reference (IOR) is needed. Additionally, the agents would have to perform mappings to the respecting peers. This is definitely not feasible for an agentenabled P2P environment. Moreover, as mentioned above, the transport layer security of JADE is not as advanced as that of the JXTA framework. Therefore in the developed approach all inter-agent-platform communication is performed by the underlying P2P layer. As the JADE ACL messages as well the JXTA messages are based on XML, agent communications can be wrapped by JXTA messages for inter-platform delivery. However, for the sake of unburden the JADE agents from the interoperability overload with the P2P layer, what would additionally violate the principles of the JADE message delivery mechanisms, each agent platform owns an Interface Agent responsible for all interoperability with the underlying P2P layer, as depicted in Figure 5.

Ework and ebusiness in architecture, engineering and construction

754

Figure 5. Utilising Interface Agents for managing inter-agent-platform communication by the underlying P2P layer. To send a message to an agent residing on an other peer the agent only has to know its name and the peername. After calling a simple. send() method the platform’s Interface Agent and the P2P layer performs delivery. The Interface Agent is also employed to translate events fired by the P2P layer objects into ACL messages ready to be delivered to the agents in its scope. 3.5 The ontology layer The current development state of the generic platform just implements the basic ontological framework that comes with JADE, namely the integrated agent management ontology, following the FIPA standards. However, a powerful meta-information layer, implementing a common, shared, explicit, and machine processable ontology is a decisive requirement of a modern system for distributed information management. Establishing system-wide ontology commitment for the access to information resources is a prerequisite for semantic interoperability and thereby for the real-practice value of the system itself. It enables agents to talk to each other by communicative acts, to share information via high-level semantic messages, and to process these messages using deeper application-specific knowledge in a consistent manner.

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

755

The benefit is that each agent retains its freedom to interpret any specific concept but on a high-level commits to understand what it is asked to do. In this way the complexity of the interoperability problem is reduced to a lean common ontological model and a number of mappings to/from the application-specific knowledge intensive datastructures. Five design criteria have been adopted from (Katranuschkov et al 2003) dominating the development of the ontology that is currently under way: Clarity. The ontology should effectively communicate the intended meaning of defined terms. Its definitions shouldbe objective and, where possible, stated by means of appropriate logical propositions. Coherence. The ontology should be coherent, i.e. it should sanction inferences to such that are consistent with basic ontology definitions. Extensibility. The ontology should anticipate the use of a shared vocabulary. It should offer a basis for a range of envisaged tasks, but it should also be possible to extend and specialise its concepts. Minimal ontological commitment. The ontology should make as few claims as possible about the modeled real world products, allowing the actors in the environment certain freedom for their own interpretations. Web-enabled. Whilst not directly related to the conceptual design of the ontology framework as such, this final issue is an essential prerequisite for its efficient use in distributed internet environments. Considering these design criteria the ontology framework will be based on the OWL DL standard (W3C 2004b), a specialisation of the Resource Description Framework RDF (W3C 2004a). The Web Ontology Language (OWL) enables the definition of domain ontologies and sharing of domain vocabularies. OWL is modeled through an objectoriented approach, and the structure of a domain is described in terms of classes and properties. From a formal point of view, OWL can be seen to be equivalent to description logic (DL), which allows OWL to exploit the considerable existing body of DL reasoning including class consistency and consumption, and other ontological reasoning. Utilising the advanced OWL DL framework and available free tools for ontological reasoning, the currently developed ontology framework for the construction domain will be an integral part of the generic agent-enabled Peer-To-Peer infrastructure, providing semantic interoperability, agent-based ontological reasoning as well as it provides for improving the User Interface Agent with user-friendly ontology based interactions. 4 DEMONSTRATOR The hybrid agent-enabled Peer-To-Peer infrastructure was designed and developed to support cross-company teamwork in virtual organisations of the construction industry. An early demonstrator developed at the TU Dresden (Großer 2003) provides first results and insights to the current development work. The demonstrator provides the following features: – Distributed information management based on documents, managed without the need for a central storage device, as e.g. a file server.

Ework and ebusiness in architecture, engineering and construction

756

– Support for dynamic work groups. Thereby real organisational structures are mapped to hierarchical peer-groups representing projects and teams. Users are represented with their respecting roles within the groups. Furthermore they can switch easily between the projects. – Autonomous agents are responsible for keeping track of the distributed resources their user is interested in. Furthermore, they generate appropriate views that map the resources to organisational structures based on resource patterns and support resource exchange. – An User Interface Agent mediates the communication between the system and the user. The screenshot of the German demonstrator below illustrates the feature of switching between different projects using the tabs on the upper screen. The navigation bar on the left side facilitates easy resource management as a Project Agent automatically assigns the resources to a structure specific for construction projects. A resource may have more than one representation within the navigation bar in order to represent different organisational structures. E.g. a construction plan can be found within a document type hierarchy, related to a company or assigned to a specific building, element or system. The resource window on the right side presents standard resource information as name and resource size, as well as the name of the owning peer. Resources without an owner entry are available locally The advanced underlying P2P network infrastructure is transparent for the user. The look and feel is similar to standard project server software. However, there is no checkin/check-out mechanism as there is no central instance. The user stores his/her resources in shared directories, that may be different for several projects. The agents propagate new resources in the network to interested project members and provide advanced search mechanisms for locating resources that match specified search attributes. Most of the work in the background is performed by two specialised software agents, namely the Project Agent and the Resource Agent. Each peer owns exactly one of each of these agents, residing on the agent application layer. The Project Agent manages all project information of the projects the user participates in and is responsible for searching, updating and managing the project resources. The local project information is updated by requests the user initiates and by inform actions the Project Agents of other peers are sending if specific events occur. The local resources itself are managed by the Resource Agent, which administrates the local resources and responds to local and global search requests respecting the particular project IDs. These two agents that act in cooperation with the User Interface Agent, that currently owns just reactive behaviours, result in a powerful ensemble managing a lot of daily information resource management tasks the user is currently forced to perform manually. However, it was only possible to develop this lightweight smart demonstrator in a straightforward manner by exploiting the powerful generic agent-enabled Peer-To-Peer infrastructure presented in chapter 3, even without the currently developed ontology framework that could represent the resources on a meta-information layer.

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

757

Figure 6. Screenshot of the demonstrator application (in German) illustrating coherent information management spanning different projects in the distributed Peer-To-Peer environment.

5 NEXT STEPS The described generic infrastructure as well as the demonstrator can be beneficially extended in several ways. Further stages of the generic infrastructure are: – The anticipated conceptual and technological progress regarding the generic infrastructure, will be dominated by the ontology framework, that is currently being developed. Following the criteria outlined in chapter 3.5, the ontology concepts described as classes and properties as well as logical implications are being compiled within a layered ontology structure. Furthermore, generic ontology processing facilities supporting agent development are currently under construction. – Many tasks currently performed by the demonstrator’s Project Agent can be delegated to a generic agent that comes with the infrastructure itself. This agent will automatically perform peer-group based information management in a generic way and provide its services to application specific agents that utilise the ontology to reconfigure the offered information.

Ework and ebusiness in architecture, engineering and construction

758

– The infrastructure efficiency can be improved by integrating more powerful generic application agents. Therefore, after performing the two previous tasks it is intended to develop an autonomous backup agent, configurable to log group information flows and to automatically perform backup storage of specified resource groups. Moreover, it is aspired to implement agents that utilise process templates in order to support standard construction information flows. As the demonstrator proved to be very efficient within the targeted scenario it will also be upgraded with additional fimctionality: – The ontology services are especially interesting for extending the demonstrator as soon as they are available. Whereas the ontology framework developed for the generic infrastructure encompasses high-level concepts and processing/reasoning facilities, to be usable for the demonstrator domain specific concepts and rules have to be developed. – Utilising this specialised ontology the User Interface Agent will be equipped with an ontology supported interface. Experiences gained from that ontology based User Interface Agent are planned to be exploited for designing a generic template for straightforward development of user interface agents, that can become a part of the generic infrastructure in a later stage.

6 CONCLUSIONS The developed agent-enabled Peer-To-Peer infrastructure approach proved to be feasible to meet the requirements of dynamic distributed cross-company teamwork in virtual organisations. However, what was achieved so far is still to be evaluated according to the specific objectives described in chapter 3.1. The goal of facilitating the information management process is met by the decentralised architecture presented in chapter 3. The P2P communication model proved to be the best choice for constituting the basic information layer. Support for virtual project spaces is provided by the peer-group concept. However, only with the added value of software agent technology in the background, an advanced framework for sharing distributed information resources can be offered. Utilising software agents in general is the crucial point for making the system efficient. Only if agent technology and an advanced ontology framework can provide for intelligent user-friendly services and allow the engineer to delegate information management tasks, the system will be competitive with centralised client/server approaches. REFERENCES Bayardo J.R. Jr., Bohrer W., Brice R., Cichocki A., Fowler J., Helal A., Kashyap V., Ksiezyk T., Martin G., Nodine M., Rashid M., Rusinkiewicz M., Shea R., Unnikrishnan C., Unruh A. & Woelk D. 1997. InfoSleuth: agent-based semantic integration of information in open and

Agent-enabled Peer-To-Peer infrastructure for cross-company teamwork

759

dynamic environments. In: Proceedings of the 1997 ACM SIGMOD international conference on Management of data. ACM Press, Tucson, Arizona, United States. CoMMA Consortium. 2000. Corporate Memory Management through Agents. In: Proceedings EWork & E-Business. Madrid, Spain. Ehrig M., Haase P., Staab S. & Tempich C. 2003. SWAP—A Semantics-Based Peer-to-Peer System. In: Gronau N. & Benger A. (Ed) Proceedings of JXTA Workshop—Potenziale, Konzepte. Berlin, Germany. Ferber J. 1999. Multi-Agent Systems: An Introduction to Distributed Artificial lntelligence. Addison-Wesley Publishers. Großer A. 2003. Untersuchung des Einsatzes von Agentenbasierten P2P-Netzwerken für das Informations management in der Bauplanung, Diploma Thesis. Institute for Construction Informatics. TU Dresden, Germany. Guarino N. 1996. Understanding, Building, And Using Ontologies. In: Proceedings of Tenth Knowledge Acquisition for Knowledge-Based Systems Workshop. (available from: http://ksi.cpsc.ucalgary.ca/KAW/KAW96/guarino/guarino.html) Jennings N.R. & Wooldridge M.J. (Ed.). 1998. Agent Technology. Foundations, Applications, and Markets. Springer Verlag. Berlin Heidelberg New York. Katranuschkov P. & Gehre A. 2003. An ontology framework to access IFC model data. ITcon Vol 8, Special Issue eWork and eBusiness. (available from: http://www.itcon.org/) Milojicic D.S., Kalogeraki V., Lukose R., Nagaraja K., Pruyne J., Richard B., Rollins S. & Xu Z. 2002. Peer-to-peer computing. Technical Report HPL-2002–57, HP Laboratories, Palo Alto. Panti M., Penserini L., Spalazzi L. & Tacconi S. 2002. A Multi-Agent System based on the P2P model to Information Integration, Computer Science Institute, University of Ancona. Rimassa G. 2003. Runtime Support for Distributed Multi-Agent Systems. Ph. D. Thesis, University of Parma, Italy. Sun Microsystems. 2001. Security and Project JXTA. Palo Alto, USA. available from: http://www.jxta.org/project/www/docs/SecurityJXTA.PDF Sun Microsystems. 2003. Project JXTA v2.0: Java Programmer‘s Guide. available from: http://www.jxta.org/docs/JxtaProgGuide_v2.pdf W3C. 2001. DAML+OIL (March 2001) Reference Description. W3C Note. available from: http://www.w3.org/TR/daml+oil-reference/ W3C. 2004a. RDF Primer. W3C Recommendation available from: http://www.w3.org/TR/rdfprimer/ W3C. 2004b. OWL Web Ontology Language Overview. W3C Recommendation. available from: http://www.w3.org/TR/2004/REC-owl-features-20040210/ Weiss M., Busch C. & Schröter W. (Hg.). 2003. Multimedia Arbeitsplatz der Zukunft—Assistenz und Delegation mit mobilen Softwareagenten. Talheimer Verlag, Sammlung kritisches Wissen Band 44, Germany.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Virtual communities: design for collaboration and knowledge creation I.L.Kondratova & I.Goldfarb National Research Council of Canada, Institute for Information Technology e-Business, Canada ABSTRACT: This paper addresses the newly emerging paradigm of knowledge dissemination and collaboration in Online Communities. The authors present the results of a pilot study of thirty existing community portals, including information about the portal architecture, fimctionality, and design details. The paper discusses the functionality of different elements of virtual community spaces such as the discussion forum, digital repository, e-learning resources and collaborative tools that are utilized by various online communities, including engineering and scientific online communities. The authors devote a significant amount of attention to the investigation of design functionality, collaborative tools and practices that support member participation and knowledge sharing. Knowledge sharing in virtual enterprises and communities of practice is facing major challenges due to a failure to align their incentives system with the objective of creating value through knowledge sharing. Special design considerations to encourage member participation and knowledge sharing in the online professional communities are discussed.

1 INTRODUCTION Communities of practice are communities of professionals and others who share knowledge and resources (Wengler, 1998). Hildreth et al. (2000, p. 35) defines a community of practice as the community which has “a common set of interests to do something in common, is concerned with motivation, is self-generating, is self-selecting, is not necessarily co-located, and has a common set of interests motivated to a pattern of work not directed to it”. The key to a successful knowledge dissemination strategy is to channel the knowledge to the communities of practice and at the same time provide means for information exchange and peer-to-peer collaboration (Wengler, 2000). An online community has to satisfy three main objectives. It has to supply content to the user, it has to encourage members to participate in the community by contributing, and it has to facilitate communication and interaction between them (Pickles, 2003). In the design of a virtual community space some functionality should be provided to “push” content to members. “There are a multitude of techniques for pushing content to and from members but the aim is for members to generate as much content between them as possible” (Pickles, 2003). These “push” functionality features include Knowledge Repository, News, Workshops/E-learning modules, Classifieds and Job offerings.

Ework and ebusiness in architecture, engineering and construction

762

Other features serve a means of “pulling” content from members of online communities. Such “pull” features include the Forum, Member directories, Member reviews, Polls and Surveys, Online and Offline events, as well as, providing Topic Experts services to the users. The rest of the Portal features should be designed to encourage member participation and collaboration. These features include online conferencing, Forums, Chat rooms and Conferences, as well as live meetings. The Knowledge Portal model for online community of practice is presented in Figure 1 (Kondratova and Goldfarb, 2003). Within this model, the Knowledge Portal site provides, for scientists, practitioners and private companies, free access to the Discussion Forum and to the Virtual Laboratory, as well as to the Digital Repository of research and scientific information. The proposed Knowledge Portal model enables basic community of practice portal requirements. These include a conversation space for online discussions on a variety of topics, as well as, a facility for posing questions to the community (Discussion Forum), a shared workspace for synchronous electronic collaboration, discussion or meeting (Virtual Laboratory), and a document repository to be used as a knowledge base (Repository) (USAID, 2004). By providing a Forum for discussions and Learning Resources for reference, the Knowledge Portal creates the opportunity for all members of the community of

Figure 1. Knowledge Portal: users and players interactions.

Virtual communities: design for collaboration and knowledge creation

763

practice to directly and actively participate in the knowledge creation and scientific dissemination process. The Virtual Laboratory, as part of the Knowledge Portal, enables joint research work on common documents, databases, projects, and contains domainspecific software tools, like, for example, UNESCO’s Electronic Support for Cooperative Scientific Research Project (UNESCO, 2004). In order for a Discussion Forum, within the Knowledge Portal, to be a place where scientific discussion, knowledge sharing and exchange will happen and new knowledge will be created, the Discussion Forum must be supported by a comprehensive digital Knowledge Repository. The participating research organizations, private companies, and industry practitioners can submit artifacts (raw data, research results, photographs, reports and preprint papers) into this Repository. A peer review process of submissions, by content experts from the user community, should be undertaken to assure the quality of submissions, as it is done in the OneFish online scientific community (oneFish, 2004). The processing of knowledge in the repository into value-added products for the industry could be done by “knowledge workers” as in the SciX portal (Gudnason et al, 2002). Knowledge workers are the new actors in the value chain of the electronic publishing process. The concept of value added services is quite important; it brings up a new model of electronic publishing, which is totally different from the old paper-based publishing model by virtue of facilitating new knowledge creation and aiding in technology transfer to the industry. To achieve this, the virtual community needs to attract highly skilled content experts as “knowledge workers” that are able to extract information contained in different research studies and aggregate it into new knowledge. Value adding could also be achieved by involving virtual community members into joint creation of new knowledge by participating in the creation of a common document, knowledgebase, or in general a “knowledge artifact”. This process brings a stimulating quality into the life of the virtual community of practice (Hildredth et al, 2000). The Knowledge Portal model is a model of the future professional community of practice. To investigate the design and functionality of existing professional community of practice portals and the implementation of the above-mentioned features of the Knowledge Portal, a pilot research study was conducted as described in the following sections. 2 STUDY ON DESIGN FUNCTIONALITY OF ONLINE COMMUNITIES This research study involved the evaluation of different online community portals, by collecting and analyzing information about the design features and ftinctionality of 30 community portal websites. The following community portal types were studied: 1 Business 2 Government and Organizational 3 Professional 4 Social. Business community portals are also known as commerce communities. In order to provide information about their product or service companies tend to create these types of

Ework and ebusiness in architecture, engineering and construction

764

portals for the community of users. The business rational for creating this type of community is that “Informed customers may be picky, but they can also be devoted customers.” (Powazek, 2002, p. 219). It has also been noted, that “people who participate in online communities are more likely to buy from the same site” (Powazek, 2002, p. 228). By providing a place for their consumers to meet, companies get a chance to get client feedback, learn about areas of improvement, learn about the demographics of their clients, about their needs and wants, and establish a loyal clientele, etc. A total of six business community portals were evaluated in this study. Government and organizational community portals are normally created and run by the government or an organization. Their purpose is educational and informative to the government/organization employees and to the general public. In addition, organizational communities frequently accentuate the importance of their initiative and try to recruit volunteers online. A total of four government/organizational community portals were studied. Professional communities—also known as communities of practice—are communities of professionals who share knowledge and resources (Preece and Maloney-Krichmar, 2000). These communities usually have a common goal to achieve as their main purpose. The main purpose of these communities is knowledge creation and knowledge communication (Lueg, 2004). A total of eleven professional community portals, representing the most interest to this research study, were tested. Social community (also known as communities of interest) portals were tested as well. The purpose of these communities is to bring together people with similar interests, hobbies, such as gardening, golf, computers, cooking, etc. These communities can also bring together people of the same religion, ethnic background, or demographic, for example teen forums, seniors’ communities, etc. (Preece and Maloney-Krichmar, 2002). A total of nine social community portals were evaluated in this study. 3 PORTAL STUDY PROCEDURE The virtual community portals were tested according to 80 different criteria arranged into the following categories, as suggested by USAID Knowledge Management for Communities of Practice Functional Requirements Matrix (USAID, 2004): 1 Content: the Knowledge Repository and articles published on the site 2 Discussion Forum functionality 3 Features: chat, news, e-newsletters, workshops, events, web-conferencing 4 Tools and learning modules 5 Search functionality 6 Membership: Access to knowledge, tools, and collaboration by members and guests, how open this community was to outsiders, member directory 7 Topic Experts as well as Moderator capabilities for forum and content submissions. The portal study template is shown in Figure 2. Study results for each online community portal were entered directly into the study template forms in the relational database. At the end of this research project, the study reports were produced for each portal category.

Virtual communities: design for collaboration and knowledge creation

765

The summary of the findings for the Community Portal study for different categories of portals is presented in Figures 3 and 4. 4 PORTAL STUDY FINDINGS The techniques used to improve member engagement and participation in online communities, in the order of increasingly stimulating effect on member participation, range from “Pushing” content to members (content generated by community Manager) to “Pulling” content from members (most of the content generated by members) and to peer-peer content generation when content is generated by members for other members, as for example in special interest groups, or sub-communities (Pickles, 2003). On this scale, as follows from Figure 3, business communities were mostly at the level of “pushing” content to members, with very little opportunity provided for members to contribute their own content (only through forum discussions) and with little opportunity for engagement. It is interesting to note that the Discussion Forums for online business communities were quite sophisticated, with multiple features used and, seemingly, constituted the “heart” of the portal. In addition, only business community portals were extensively utilizing the option of sending updates by

Figure 2. Community portal study template. email, again giving an indication of the predominantly content “push” mode of the portal. Government and organizational online communities that were studied also seemed to be designed to disseminate content mostly in the “push” mode, with little opportunity for community members to contribute content into the repository (less than 25%).

Ework and ebusiness in architecture, engineering and construction

766

However, some member feedback was accepted in the form of document ranking (more than 75% of portals had this functionality). In addition, polls and the survey option were quite popular with Government/ Organizational portals indicating desire to receive user’s feedback and collect members’ opinion. It is interesting to note that the “Topic Expert” option was used by Government and Organizational portals the most, so was the option to create sub-communities. However, these sub-communities did not constitute special interests groups created by members for peer-to-peer collaboration and content creation, as mentioned earlier, but rather were organized for administrative and content management purposes. We found that Professional community portals encouraged the submission of documents and articles by members in to the repository the most, thus acting in both, the “pull” and the “push” content modes. It is interesting to note that the option to rank articles was not available for the Professional community portals studied. On the contrary, the option to comment on articles was quite popular—about half of the Professional community portals had this option. Other common features of the Professional community portals, found in more than half of the portals we studied, were as following: the portal repository was moderated and the members had the option to submit and categorize content in the repository. The search option for the Professional community portals was mostly well developed and quite comprehensive and, among others, included options to search people, forum postings and documents in the repository. Member directories were available for seven out of eleven Professional community portals studied, with comprehensive member profiles that included the total number of documents submitted by the author and a picture or avatar of the member. “Topic Expert” functionality was also quite popular with the Professional community portals, where the Expert directory and information on the field of expertise of the expert were found in more than half of the portals evaluated. According to Hildredth et al. (2000), one of the most difficult parts of operating in a distributed environment is to facilitate the evolution of the community and the development of the relationships. The case study conducted by Hildredth et al. (2000) confirmed the importance of maintaining face-to-face contacts for community building. Thus, offline events conducted by the community of practice can potentially become quite important for online community building. As shown by our study, offline events were popular with less than half of the Professional portals studied, revealing the missed opportunity for professional communities to maintain face-to-face contacts alongside with online contacts, as it is done much more frequently in government/organizational communities.

Virtual communities: design for collaboration and knowledge creation

Figure 3. Content, Repository, Discussion Forum, Features and Tools for online communities.

767

Ework and ebusiness in architecture, engineering and construction

768

Figure 4. Search, Membership and Expert options for online communities studied. Online Professional communities, out of all portal types studied, had the largest number of popular “feature” options available, including an events calendar, e-newsletter, recent news, workshops, job advertisements and software downloads. In addition to this, only members of online Professional communities had personal web space allocated for them. However, we found that “blogging”—“the art of using a personal web space for recording your own thoughts, ideas and experiences” (Pickles, 2003) was not very popular for the Professional communities portals, even though community members had some personal space available to record their thoughts. Most of the social community portals had moderated repositories and well developed discussion forums. Surprisingly, out of all portal types studied, social community portals had the largest number of learning resources available (this might be the result of the majority of social portals studied being seniors’ portals). In contrast to this, less than half of Professional portals had online learning materials available for community members. Portal features not used by any of the communities were: the web conferencing/whiteboard option, providing a custom email address to the member and the expert ranking option. The functionalities that were used rather rarely: assigning roles to community members, spell checking for the forum and the option to receive updates by email (this was popular only with business communities), as well as the option for the forum to act as a listserve (also popular with business communities only). In addition to

Virtual communities: design for collaboration and knowledge creation

this, the option to create Government/Organizationalportals.

sub-communities

was

only

769

available

for

5 CONCLUSIONS Knowledge sharing in virtual organizations and communities of practice is facing major challenges and defeats due to a misalignment between the incentives system and the objective of creating value through knowledge sharing (Kondratova and Goldfarb, 2003). As well, private companies and their employees tend to be inherently hostile to knowledge sharing (Husted and Michailova, 2002). To overcome this knowledge-sharing hostility, some organizations utilize innovative knowledge-sharing tools such as, Xerox Company’s “Docushare” tool for document sharing by virtual teams. Olson and Olson (2000) describe the subtle suggested improvement in the shared document repository system design that potentially could increase the adoption of shared information repositories. According to their observations, a simple design change that would make the reading activity of the manager who monitors team contributions to the shared information repository in groupware, visible to the contributing team members, would dramatically increase the level of contributions to the repository. Clearly, there is a need for similar studies and improvements for virtual collaborative spaces on the Internet, that are intended to serve as knowledge creation and sharing spaces not for employees of the individual company, or a group of companies, but by the diverse participants in communities of practice. Our pilot study is a first attempt to evaluate the use of particular design functionalities for online community spaces in order to influence the level of member participation. As an outcome of this study, we developed a study template and a study procedure for studying community portal functionality; we evaluated the study procedure by conducting a pilot study of different community portals. The limitation of this study is that some of the Professional and Government/Organizational community portals that were studied had paid membership or membership by request option. Thus, information on the functionally of these types of portals was gathered based on the description of the portal functionality posted to attract new members and was not experienced directly. For our future study program, a procedure that helps to overcome this limitation will be developed. It is planned to test indepth a large number of professional community portals to draw more precise conclusions on the functionality and design features used in these portals. This will allow the generation of better recommendations on how to improve the design and fimctionality of Professional community portals to enhance member participation and knowledge sharing for online communities, as well as improve learning opportunities that are currently underutilized. ACKNOWLEDGEMENTS The authors would like to acknowledge the support provided for the project by the National Research Council Canada, valuable input from my colleagues at NRC on the

Ework and ebusiness in architecture, engineering and construction

770

study design, and the hard work and dedication of the University of New Brunswick Computer Science student Magda Piasecka that participated in the development of study template and conducted the pilot study of more than 50 community portals. REFERENCES Gudnason, G., Bjork, B.-C. and Turk, Z. 2002. SciX: open repository for scientific information exchange and value added services for the construction industry. eWork and eBusiness in Architecture, Engineering and Construction, Proc. of the Fourth European Conference on Product and Process Modelling in the Building and Related lndustries, A.A.Balkema Publishers: 667–672. Hildreth, P., Kimble, C. and Wright, P. 2000. Communities of practice in the distributed international environment. Journal of knowledge management 4(1): 27–37. Husted, K. and Michailova, S. 2002. Diagnosing and fighting knowledge-sharing hostility. Organizational Dynamics 31(1): 60–73. Kondratova, I. and Goldfarb, I. 2003. Design concepts for Virtual Research and Collaborative Environments, in Knowledge Management in Architectural, Engineering and Construction, 10th ISPE International Conference on Concurrent Engineering: The Vision for Future Generation in Research and Applications, J.Cha et al. (eds), Swets & Zeitlinger, Lisse, Portugal, 797–803. Lueg, C. 2000. Where is the action in Virtual Communities of Practice? In Proc. of the D-CSCW 2000 German Computer-Supported Cooperative Work Conference “Verteiltes Arbeiten—Arbeit der Zukunft” September 11–13, 2000, Munich, Germany. Published electronically. http://wwwstaff.it.uts.edu.au/~lueg/papers/commdcscw00.pdf Olson, G.M. and Olson, J.S. 2000. Groupware and computer-supported cooperative work. In Julie A.Jacko and Andrew Sears (eds), The human-computer intemction handbook: 583–595. New York: Lawrence Erlbaum Associates Publishers. oneFish. 2004. OneFish research community. Online. http://www.onefish.org/ Pickles, T. 2003. Practice Guide: Techniques for Engaging with Members. Published electronically. http://www.sift.co.uk/practice/tips/index.html Powazek, D.M. 2002. Design for community. The art of connecting real people in virtual places. Indianapolis. Preece, J. and Maloney-Krichmar, D. 2000. Online communities: focusing on sociability and usability. In Julie A. Jacko and Andrew Sears (eds), The human-computer interaction handbook: 596–620. New York: Lawrence Erlbaum Associates Publishers. UNESCO. 2004. UNESCO’s Electronic Support for Cooperative Scientific Research Project. Online. http://www.unesco.org/webworld/build_info/virt_lab.htrnl USAID. 2004. Knowledge for development: Best Practices: Technology and systems. Published electronically. http://knowledge.usaid.gov/techandsys.html Wengler, E. 1998. Communities of Practice. Cambridge, UK: Cambridge University Press. Indiana: New Riders, a division of Pearson Technology Group. Wengler, E. 2000. Communities of practice: the key to knowledge strategy. Knowledge and communities. Butterworth Heinemann: 3–21.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

The design framework—a web environment for collaborative design in the building industry M.Huhn Bergische Universität Wuppertal, Germany ABSTRACT: A Design Framework (DFW) has been developed which supports collaborative design of large, element-based building models. The DFW is both an abstract architecture of a design environment and a concrete, implemented framework which connects design stations. The approach does not requires a central data base. Instead, data remain in their local, native data bases. The framework provides all the services which are necessary for the collaborative design, such as synchronization, notification services, viewing services, access control, user and rights management. The DFW is designed to work on a web platform, it takes care for the specific conditions of a web environment incl. lower bandwith, communication breakdown and offline phases.

1 INTRODUCTION 1.1 Target industry and mode of operation Steelwork and plant design are just two samples of areas where designers work in parallel at digital building models today. Engineers working in the same model domain subdivide the model into partitions. Each designer owns a partition and works on it but needs read access to the whole model. Several designers mutually access intersecting sectors. Engineers in different domains (e.g., HVAC and steelwork) access the same geometric areas. 1.2 State of the art Recently, the building industry uses two approaches in supporting cooperation. On one hand, commercial providers run Internet platforms which host project documents. This works pretty well but addresses the classical document-centric approach only: Drawings and other documents represent the design goal. But in many domains (steelwork, timber construction, glass, HVAC etc.) these documents are just the outcome of a digital building model (or partial model). Here, the model is both design medium and goal. Models reside in local systems and remain isolated. Documents are potentially outof-date. On the other hand, product modeling technology provides a means of forwarding real models between different design systems which use native data models internally. This, of course, does not include any automatic conversion between different partial models.

Ework and ebusiness in architecture, engineering and construction

772

But in many projects, product models like PSS (DSTV 2000), and the LPM (Eastman 2001), have succeeded in passing relevant design information. The more general IFC standard (e.g. ST-4 2003) still has to show its impact. Roundtrip engineering is not inherently supported by product models. This is due to the lack of means of partial access and navigation as well as the usual bottleneck problem. Even the transfer of models can serve sequential design only. Designers cannot collaborate directly. 2 THE DESIGN FRAMEWORK 2.1 Idea and architecture The Design Framework (DFW) links design systems (CAD) into one design environment. Different systems run in different places, they may even address different partial models. Figure 1 shows that every CAD system is wrapped by a specific adapter, resulting in a uniform interface on the connector part. There is one connector per CAD system and one connector for the central management components. All the DFW connectors form a kind of ‘design bus’. Each CAD system uses it’s own native data model. The design bus employs a uniform product model, e.g. the PSS. The wrapper components do the mapping. Designers work on different model partitions. The complete building model instance is ‘virtual’: It is the

Figure 1. Principal parts of the Design Framework. aggregation of all the distributed model instances in terms of the employed product model. Local systems work as peers. Each system may serve services conc. its own model part. At the same time, it may be a client of services of other systems of the framework.

The design framework

773

2.2 Demands on design systems Each native design system has to fulfil a number of requirements in order to work with the DFW. These abilities may be accomplished by means of the system wrapper. – A unique identificator as well as a version number must be maintained for every first level object of the product model. – It must be possible to differentiate between objects of the own model part and view objects of foreign model parts. (See below for the view concept) – The design system must provide slots for the handling of a number of object events. For instance, the system should be able to notify the environment when objects are created, modified or deleted. 2.3 Implications and discussion The participants of the DFW must agree on communicating at the semantic level of a certain product model. This means, that everything in a foreign model which is of interest can only be ‘imported’ via product model. In practice, this is not that bad: Using data exchange via STEP physical file, there is the same restriction right now. There is no digital building model in ‘one place’. Instead, it is distributed over several design systems. Compared to a central data base with check out/check in mechanisms, this has some advantages: – The particular designer does not need to check out in order to start. He can start working immediately, even offline. – All auxiliary elements (views, coord. systems, working planes etc.) remain in the model, nothing gets lost after checking in to a neutral model. – The designer retains control over ‘his’ model. In practice, this solves somes psychological and legal issues which are sometimes harder to address than technical challenges. – Every design system has additional semantics in its model. This does not get lost in a check in/check out cycle. – The major part of the local model does not need to be transferred over the wire. Some things can be achieved alike with a central data base. – Archiving can be done in terms of the product model as a central service of the Design Framework. – Documents can be derived as usual. They represent the current design state and are collected and hosted on a central document server. – Users might wish to apply commands to objects of the whole model. For instance, a general arrangement drawing should be derived. This is not directly supported as the DFW does not implement CAD functionality. Nevertheless, it can be implemented in one of the involved CAD systems by using DFW query services. Certainly, there are drawbacks too: – Older design systems might not have the usual event handling. Without notification capabilities they loose essential framework functionality.

Ework and ebusiness in architecture, engineering and construction

774

– The DFW does not support version branches. The short transaction principle normally allows for a single branch only. If designers break the rules and work both offline and without locking, two or more branches of the same object can be created. This requires synchronization by hand. – Long offline phases lead to large model caches, see below. This might compensate some advantages. – There is no overall model versioning. In a ‘living’ framework, we would need to stop all processing in order to get a total snapshot.

3 ABSTRACT DESCRIPTION 3.1 Abstraction levels The framework has been described on two levels. The system level abstracts from concrete building elements. It uses general concepts like object, model, owner etc. The single designer ‘sees’ the DFW as one system which deals with the (building design) project. He can use and control that system through the local workstation. The user knows that he owns only a part of the whole digital building. At the component level, the DFW is decomposed into units which are distributed and loosely coupled via the Internet. In terms of software development, each

The design framework

775

Figure 2. Abstraction levels of the Design Framework.

Figure 3. WSDL schema. unit can be developed independently, it is described by interfaces only. Every level employs its own class model and is described by using a modified UML representation. The project level in figure 2 just shows the ‘real design world’ in terms of business cases. 3.2 Mapping The business cases of the project level have been collected by a survey of Pegels & Koch (2002). They have been classified and mapped onto system level scenarios. These scenarios are externally expressed by use cases and internally implemented by abstract scenarios (Huhn 2004). The behaviour can be finally mapped down to the level of services which are implemented by components (Pegels & Huhn 2004). The services are described by a simplified form of the WSDL standard. WSDL (Christensen et al. 2001) comprises an abstract, implementation-independent representation of functionality (port types) as well as services which implement that functionality by using a concrete language binding, figure 3. The DFW employs some of those concepts and expresses services in the Unified Modeling Language UML by describing.

Ework and ebusiness in architecture, engineering and construction

776

Figure 4. Sample of a DFW component interface. – port types by interfaces of stereotype portType, – operations by methods, – SOAP message parameters by classes of stereo-types of XML schema data types like xsd:complex Type etc. 3.3 Benefit By using the abstract description of the DFW, real-world design scenarios can be represented and ‘simulated’. The DFW can be refined in order to support crucial design scenarios. On the other hand, the component level may serve as a template for an actual implementation. The formal description in terms of web services does not imply a certain platform and allows the independent development of components. 4 CONSISTENCYISSUES 4.1 Consistency, synchronization and notification Different abstractions of the same building part need to be consistent, e.g. physical beam and the element(s) used for it by the structural analysis. This can be evaluated and decided by an engineer only. The DFW supports the usage of different domains and helps in tracking those cross-domain relationships, see below. The ‘same’ model object might be used in different design systems at the same time. Several engineers ‘see’ that object, they even may try to change it concurrently. Although there is a kind of local ‘proxy’ in every design system, a model object should have one

The design framework

777

consistent state only. This is the problem of synchronization. Offline phases are necessary to support. The DFW tracks object locks and prevents parallel updates of objects. In a distributed environment, a local designer wants to get notified of model changes of interest. In turn, he wants that the DFW notifies others of changes he made. 4.2 Is synchronization always necessary? Surveys have shown that designers do not want always be synchron. They need a reliable environment, they want to control an update of ‘their’ model part, they do not want to be disturbed by instant messaging or changing. For this reason, the DFW introduces the concept of views. Remote model parts are presented locally in views. The actual representation depends on the local design system and can even be a BOM in a report system. People can choose among different view types. – A static view is just a snapshot of a model portion. The view client is responsible for any update. – The status view enhances the static view: Modifications are reported automatically to interested clients. The client knows that an object has been changed, but he does not know how. Again, he is responsible for any update. – In a live view, all model changes are immediately communicated to clients. Both the server and the client of a view choose their view type. This results in a combined behaviour. Relevant model versions must be kept. At the moment of clearance, the objects have to be up-to-date, subsequent changes must not alter that version any more. This is supported by the framework through a clearance concept. Technically, a copy of the appropriate model part is being made. 4.3 Explicit vs. implicit synchronization Normally, the DFW supports implicit synchronization. The system takes care for synchronization of the distributed model as part of every user command. The user does not need to explicitly perform any sync. command, he gets notified according to the chosen view types. On the other hand, explicit synchronization is necessary in case of errors. The system needs to provide the means to fix corrupted data. 4.4 Online vs. offline Synchronization does not necessarily require permanent online status. The local wrapper as well as the central project component do a caching. If the system goes online again, changes are communicated. On the other hand, isolated changes require the reservation of objects for exclusive access. This is supported. Finally, the user might be allowed to over-write even objects which have not been reserved. In this case, synchronization cannot be executed automatically. The user needs to choose the valid object version branch.

Ework and ebusiness in architecture, engineering and construction

778

4.5 Distributed objects The—virtual—building model instance is made up of objects called vobjects. Every single vobject will be created only once, this means by one local design system resp. user. The appropriate native object(s) reside in one local model. The local system is said to have creatorship of the vobject. Normally, the system with the creatorship of a vobject will also host that object. It is said to have ownership of the vobject. The DFW links the management of rights to the ownership, the owner is deciding if the vobject is exposed for modification or not etc. But it can be necessary to change the ownership during the life of a vobject. For instance, a new joint will be attached to a column of a foreign model part, all parts belong to the own model part at first. The fabrication structure differs from the design structure, some plate is welded on the column in the shop, the other parts are assembled on site later. In this case, the plate should be moved to the foreign model, the ownership changes. Nevertheless, it is important to maintain the creatorship information. In the sample, only the creator might have the means to modify the joint correctly. Sometimes, attributes of a vobject are created by different design systems. This happens when a system does not fully implement all aspects of a vobject, it is neither able to create the attribute nor to set it to a value. In this case, we have an object owner but different creators. Early implementations show a lot of problems here. An alternative solution is the ‘artificial’ introduction of another model domain: In this case, two vobjects exist in parallel. Parallel domains exist anyway, e.g. analysis and steelwork. Objects of different domains are usually interrelated somehow. The DFW does not reflect specific mappings but introduces a more general relationship called rulership. This means that a vobject is ruled—or just influenced—by vobjects of another domain. This leads to automatic notification and clearance services by the DFW. The correct adaptation of a vobject to any new situation is still up to the engineer. Rulerships can be defined bi-directional. 5 CONCLUSIONS The Design Framework provides the means for linking engineering workplaces into one building design environment. It suits best for CAD systems which address the same model domain, but supports different domains as well. The connected systems have to share the same product model which defines the level of communication. The Design Framework addresses areas where designer work mutually at the same model. It does not specifically support sequential design. 6 OUTLOOK In a next step, areal-world implementation is intended. An adequate user interface of all the aspects of the collaboration will be developed. This interface should not only fit mto a specific CAD system but should be of common benefit.

The design framework

779

REFERENCES Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S. 2001. Web Services Description Language 1.1 (WSDL) Eastman, C. 2001. Overview of CIS/2. Georgia Tech University German Steel Construction Association (DSTV) 2000. Standard description for Product Interface Steel Construction. Düsseldorf: Deutscher Stahlbauverband DSTV Huhn’M. 2004. Abstract and concrete scenanos m concurrent in concureent engineering. In Proc. of the international Conference on Computing in Civil and Building Engineering. (in press) Pegels, G.; Huhn, M. 2004. Grundlagen vernetzt-kooperativer Planungsprozesse für Komplettbau mit Stahl, Metall, Holz und Glas. Report II. Wuppertal: Bergische Universität Pegels, G.; Koch, A. 2002. Grundlagen vernetzt-kooperativer Planungsprozesse für Komplettbau mit Stahl, Metall, Holz und Glas. Report I. Wuppertal: Bergische Universität Structural Analysis Model and Steel Construction. IFC Project ST-4. 2003

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Collaborative work practices in Turkey, five case studies Alexis Sanal Istanbul Technical University, Turkey ABSTRACT: Current work practices in five Turkish AEC sector organizations are observed to better understand how it is knowledge workers employ physical and virtual environments and ICT tools to enable their collaborative work activities. The objective is to suggest insights and actions to enhance the relationship of activity, place and tool to leverage the potential to create new knowledge through teamwork. The case studies probe into the organizations’ objectives of collaborative work activities and how the tools utilized and the environments engaged support those objectives. The common themes emerging from the case studies are considered alongside three workplace-making perspectives that attempt to expound the potentials of knowledge workers ability to generate new ideas through their work practices. Each theory shares the position that knowledge work is either enabled or hindered by the physical and virtual environment in which the activity is carried out and by the tools used to assist the activity. In conclusion, I suggest two actions Turkish organizations can consider to explore available opportunities in their existing knowledge capital and to engender a collaborative practice with external stakeholders in order generate new products and services. This research is a first effort in a broader initiative to motivate a workplace-making methodology aimed to deliver sustainable workplace accommodations appropriate for the context of Turkey.

1 INTRODUCTION Effective collaborative work practices are important to any organization trying to increase productivity in their knowledge capital. Knowledge work is typically complex, requires multi-disciplinary teamwork and employs a variety of emerging information communication technology (ICT) tools that are multi-faceted and imperfect. Currently the AEC sector of Turkey is transforming from a manufacturing base to a hybrid with the service sectors and therefore investing more resources into their intangible assets. It is in this context I explore the relationship between knowledge workers, where they collaborate with clients, consultants and partners and what their ICT tool preferences are to facilitate those exchanges. The broader objective of this research is to frame a methodology and practice of workplace-making that can deliver sustainable office accommodations in Turkey. The outcomes and insights from this endeavor benefits the

Collaborative work practices in Turkey, five case studies

781

AEC sector in better industry collaborative practices and in developing future workplace services and products in office markets locally and internationally. Contemporary workplace makers give various theories to the significant relationship between work activities, physical and electronic places, and ubiquitous ICT tools. The first is an EU Fifth Framework research consortium led by the design consulting firm DEGW, developing a model to generate Sustainable Accommodations for the New Economy (SANE). The SANE Project is defined by the changing workplace in the new economy with a broader vision of making propositions towards the ‘intelligent city’. SANE maintains the potential impact of ubiquitous computing is greatest for collaborative work, ‘since virtual collaboration liberates the individual from having to move to a colleague’s current location to work with them’ (Harrison et al. 2002). Another workplace-making proposition is from the US research group, Appliance Studio, trying to understand how technologies interact with people. In their New Knowledge Environment white paper they assert ‘most teams undertaking knowledge work are performing significantly below their potential because of the poor state of the environment and tools with which they work’ (Sharpe 2002). A further theory is from the MIT Workplace Group who recently partnered with Cambridge University to investigated how physical and IT infrastructure can foster the involvement of customers into corporate research and development environments—termed ‘embedding’ (Joroff et al. 2004). The general idea is that work cannot be described independent of the circumstances and settings in which it is conducted (Horgen 1999). Through interviews with management, observation of their workplace environment, and inventory of ICT tools employed I anticipate to reveal the preferences to use physical or virtual places and to employ various ICT tools. In each case study the organization’s objectives for collaborative work activities are highlighted and their current utilization of virtual and physical work settings, communication technologies utilized are learned to understand how they use these modes to support their objectives. The research is a reconnaissance approach to identify opportunities for actions and indicate where workplace-making practices are currently positioned in Turkey. I will share unexpected findings as well as common themes amongst the situational cases. In conclusion, I make recommendations to advance collaborative environments in Turkey’s workplace accommodation paradigm. 2 CONTEXT The AEC sector of Turkey’s is one of the countries leading industries and many Turkish based construction corporations with internalized architectural and engineering services take part in international civil and large scale building projects. In recent years, pervasive computing has been a key driver for Turkish organizations to access and share knowledge as well as to enhance project team coordination. Mobile telecommunication has a higher penetration than the US and telecommunication investors are focusing energies into value added services. Recently, the government has laid the infrastructure for broadband communication, but mobile computing has only recently taken roots. The McKinsey Global Institute Report on Turkey looked at eleven growths sectors of Turkey. Of those sectors identified three (residential construction, steel and cement) are within the AEC

Ework and ebusiness in architecture, engineering and construction

782

sector and two (telecommunication and electricity) have meaningful implications for the workplace accommodation markets. McKinsey highlights organizations are working below the productivity potentials and significantly below best practices in other nations. Operating under potential capacity was more severe for the service sector, but their investigation found organizations changing management styles learned from best practices abroad or non-traditional management styles are far more productive than those still operating within Turkey’s traditional management models. 3 CASE STUDIES The five case studies are selected on four criteria: they are within the AEC sector in its broadest terms; identified by peers as innovative organizations; investing in their knowledge assets; and working internationally. I also selected a range of organizational sizes and years of establishment. This has resulted in: an office furniture manufacturer; a contracting corporation with many building product manufacturing companies; a midsized structural engineering office; a technology company offering services and products in IT networks, rapid prototyping product design and simulation; and a leading 3D software development startup based in the US with one of their senior software developers situated in Istanbul. In each case I first conducted an interview focused on: a) how the organization engages four activities of collaboration (learning and training, information exchange/coordination, idea creation/solutions and deliberations), b) where these activities occurred, c) which tools would be employed and d) how given no limits on resources, time or management support, what changes could be made to foster teams to perform more effectively. After the interview their workplace was observed with special attention to any place (virtual or physical) they identified where their collaborative work occurred and surveyed the tools and IT resources supporting collaborative work. Some office observations allowed for impromptu conversations with the people in the office and further conversations with the interviewees. The cases are presented by the number of years the organizations have been established. 3.1 Nurus Nurus is a manufacturer of office furniture established 70 years ago by the two current holders’ grandfather. Since then Nurus has evolved into Turkey’s leading up-market office furniture manufacturer expanding and competing in Europe and the Middle East. After a decade of advancing their manufacturing (including mechatronic technologies) and supply chain management they have shifted their management energies into strategic changing management practices and IT infrastructure planning. This later change has heightened their awareness to leverage their knowledge capital and value-added services. Recently, NURUS made a spatial shift to move the exports, marketing and sales groups to one location in a central business district on the European side of Istanbul. This shift was to consolidate their human resources and synergy amongst internal groups, as well as allow better access to international partners and clients. Within the year they will implement an extensive extranet service for information sharing, project coordination, data management and customer service/sales service support feedback. This investment

Collaborative work practices in Turkey, five case studies

783

intends to electronically link their network of international and national sales agents, internal groups, the Ankara factory and their new showrooms abroad. They expect the former shift into a hybrid, virtual and physical office environment will be a catalyst for changes in their human resource underpinning. 3.1.1 Objectives of collaborative working • Extract client’s or design team’s ‘needs’. • Exhibit and disseminate product information, details and material specifications. • Train agents in foreign markets of new products, services and sales practices. • Coordinate proposed offices products with project design team. • Collecting data and information about a client environment and current workplace. 3.1.2 Interesting findings • Institutionalized various work forms to ensure interviews and observations with clients, project visits and project design team coordination is standardized internally from sales groups to design groups. • NURUS highlighted they approach the office market with the intention to share their experience and knowledge. • The future extranet will integrate agents and showrooms from abroad, but a strategy to integrate these stakeholders into the physical environment has not been established. 3.2 Yapi Merkezi Yapi Merkezi was established in 1965 as a civil and building engineering project based organization. Today they are a one of foremost contracting corporations in Turkey for rail, heavy construction, building complexes, and restoration. Through their evolution they have internalized many services and expertise including engineering, architecture, real estate development and manufacturing a variety of building products. Yapi Merkezi has always given great importance to their engineering and project design group’s ‘expertise’. They have dedicated resources to an internal research and development group who publishes articles and attends international conferences as well as invested in a substantive on-site library including an online catalog search engine. Yapi Merkezi is currently located in the Asian side of Istanbul in their self built Campus. In planning their campus they constructed a purpose built facility for meetings and external collaborations. This building consists of two small sized meeting rooms, one mid-sized meeting room and a larger conference room. Each room is equipped with broadband access and telephone conferencing, while the larger rooms include digital media and white boards. The conferencing room is also equipped with a printable whiteboard, a stationary computer (with relevant software) and furniture that can be easily moved into a variety of configurations. Yapi Merkezi’s has developed a corporate culture in focusing on ‘reliability’ and ‘highest quality’ products, services and professional practices. This corporate culture extends to how to engage consultants, partners and clients in electronic and physical settings. Since the mid-1990’s they have prioritized investments in advanced IT

Ework and ebusiness in architecture, engineering and construction

784

infrastructure and intranets both on the campus and on construction sites (including satellite services in remote regions). More recently Yapi Merkezi enhanced their management and communication practices to comply with International Organization for Standardization (ISO). They found the time and resource invested to comply with ISO professional practice standards noticeably improved communication flows and made project coordination more effective. Yapi Merkezi is also very conscientious on protecting their ‘know how’—particularly in the physical environment of the campus— seeing it as the keystone of the company’s assets. 3.2.1 Objectives of collaborative working • Coordinate design with internal and external stakeholders. • Frame broad picture project concepts, strategies and implementation approaches with project team stakeholders. • Solve design and technical problems amongst internal and external team members. • Market to clients and partners quality, reliability and advanced ‘know-how’. 3.2.2 Interesting findings • Invested in a significant intranet and off-site IT infrastructure to communicate to project teams for over a decade. • Put cameras on construction cranes, but till date only used information captured for marketing purposes. • To transfer the highest density of information in the shortest amount of time, face to face communication was seen most effective. 3.3 Erdemli engineering Erdemli Engineering is a structural engineering firm established over 20 years ago by Mr. Erdemli. They are currently 12 people, half are structural engineers and the others are either drafting or support staff. Erdemli Engineering has established a local reputation for bringing advanced knowledge into existing local construction abilities and practices in both civil and building projects. They are keen to export their services to foreign markets, but to date have only collaborated with foreign consultant teams on projects situated in Turkey. Erdemli Engineering is located in a building originally built for apartments in a central location of a mixed-use district on the European side of Istanbul. The organization prefers to collaborate with external partners, consultants and clients outside their offices and conduct project coordination via email. For meetings that occur in the oifice, they have a larger meeting place in Mr. Erdemli’s office which is sized to accommodate large groups, while colleague to colleague meetings occur at individual desks. The office is about to implement a comprehensive data management and project coordination intranet to take advantage of a more immediate access to shared information. Yet in the physical environment, the engineer’s direct horizontal and vertical surfaces are filled with project information including reference materials, project details, and project scheduling. The

Collaborative work practices in Turkey, five case studies

785

work activities undertaken where described as highly routine but each project is seen as a new opportunity to advance and strengthen their knowledge, practices and experience. 3.3.1 Objectives of collaborative working • Learn design preferences of clients and consultant team. • Project design coordination with consultant teams. • Design and technical problem solving with internal engineers and consultants. • Transform product specifications and make product modifications with suppliers. • Attend local university seminars and lectures. 3.3.2 Interesting findings • All the engineers are from the same University. The engineers felt this nurtured the offices social dynamic and a priori understanding of ‘how things are done’. • Digital cameras were used to capture site observations to relay information and coordinate findings with internal engineers and consultant groups. • The walls and desks where treated as surfaces to visualize project information and personal expressions. 3.4 InfoTRON Founded ten years ago, InfoTRON is the leading distributor of advanced software, hardware, and services for product design and development, IT networks, digital media design, and simulation sectors in Turkey. One of their recent services is to broker the unused capacity of rapid prototyping facilities, powerful multi-media computing facilities and freelance technical persons in Turkey to European and local markets. Currently InfoTRON has their head offices on the Asian side of Istanbul with three other locations offering different core competencies. The software development core is located in Ankara at the Middle Eastern Technical University Techno park, the rapid prototyping product development core is located further eastward on a major artery in Istanbul and their European interface is located in Siemens E-Excellence Center in Munich, Germany. InfoTRON is unique in that many of their customers for their products are intern clients and partners for their services. This has led to a very conscious effort to train sales staff into knowledge network human resource management. It was explicit that sales people should not be in the office, but out in client spaces and fostering their networks. The sales people are responsible for the project management and coordination with a team of technical experts. In projects where the ‘know-how’ extends beyond the human resources or facilities available within the organization the companies knowledge network is tapped into to identify the most capable expert or facility. This informal network has become a substantial intangible asset in their organization. 3.4.1 Objectives of collaborative working • Assessment and benchmarking customer’s environments for product specifications. • Render design services with complex technical teams.

Ework and ebusiness in architecture, engineering and construction

786

• Coordinate excess capacity of technical facilities. • Construct social networks with clients and partners. • Learn new market trends, products and services in exhibitions and periodicals. 3.4.2 Interesting findings • InfoTRON demonstrated a high dexterity in using virtual environments to coordinate and disseminate information. This included remote-awareness technologies to see who was in the office, coordinate ‘critical path’ schedules of design projects and track services for product sales. • Participated in collaborations where their technical staff would be physically situated in external organizations environments for extended periods of time. • Used their hybrid environment to display awards, trade-shows, product poster, and success stories. • Nestled 2 organization’s physical places in research and development science parks. 3.5 Splutterfish This recently founded start-up company, with an address in California, is a small organization comprised of leading computer graphics software developers extending over four counties and five cities. The community of expertise in computer graphic specific to 3D Max software rendering engine and support plug-in modules is global, yet very intimate one of these experts is based in Istanbul. The founders of Splutterfish and the expert situated in Turkey met ten years ago online after his first plug-in contribution to the 3D Max program developer community. Their initial communications and exchanges where via email and online forums, but after some years of correspondence they met face to face at SIGGRAPH (an annual trade show of leading digital technologies and applications). This meeting, subsequent knowledge and project exchanges laid the grounds to consolidate distributed expertise into one start-up organization to develop the Brazil rendering engine. This start-up’s size consisting of a ‘crew’ of seven should not be underestimated, as their clients include the distinguished animation and rendering houses in San Francisco and Los Angeles. The crew member of Splutterfish in Istanbul works comprehensively in electronic settings with his only physical environment extending to workstations at his home and the annual SIGGRAPH Convention The companies only assets are their intangible intellectual property synthesized into software solutions and hence security of their linked electronic environments is of highest importance. Yet they have extended their environment to include a selective number of contributors who are often clients, colleagues and potential competitors to ensure direct and immediate feedback loops on their products and current knowledge trends. The organization employs five electronic settings loosely linked to conduct their exchanges: their website; an on-line forum; an IRC (internet relay chat); email; and an electronic ‘repository’. Their preferences to employ one over the other are dependent on the type of information and security of the information exchanged. The first three have a public space and a discrete membership places while the later two are private only.

Collaborative work practices in Turkey, five case studies

787

3.5.1 Objectives of collaborative working • Coordinate components of Brazil’s software package. • Respond to client issues and suggestions. • Engage community of interest and current information and knowledge. • Exchange work and track changes. • Mentor and create inclusive communities to foster expertise and knowledge exchanges extending into local and global networks. 3.5.2 Interesting findings • Established a synergy of expertise merely independent of the physical environment. • Maximized physical space intensity utilizing only a home desk and an annual convention. • Use electronic environment for dynamic and immediate feedback from customers. • Developed a remote-awareness plug-in for their crew to alert persons when other person online types another’s name to get their immediate attention.

4 LEARNING FROM OTHERS & COMMON THEMES 4.1 SANE 4.1.1 Summary Two results of the SANE Project (Harrison et al. 2002) are the Space Environment Model, a tool for workplace evaluation and the SANE Strategy, a workplace implementation strategy. The SANE Strategy is defined by four parallel trends meant to improve the workplaces’ contribution to quality of life and social, economic and environmental well-being: 1) Intensification of the use of space and time; 2) Reduction of waste; 3) Ensuring energy efficiency; and 4) Organizational responsibility. Although, the SANE Strategy is outside the scope of this research, it is important to be aware of what the Space Environment Model aims to achieve. The Space Environment Model is an elaboration from a tripartite analysis tool called the Hybrid Work Environment Model developed by DEGW for workplace consulting. The later tool attempts to decipher organization’s priorities to: 1) access knowledge (public, privileged or private), 2) positioning of work tasks in either physical, hybrid or virtual work setting and 3) determining if the organization is a self-contained organism or an organism within the greater urban infrastructures. The Space Environment Model tool goes beyond these three dimensions into the broader context of an organization’s cultures and multitude of potential settings work activity may be carried out in. It considers that preference given to a work setting to support a work activity will depend on three considerations: ‘mediating factors’, ‘physical landscape’ and ‘suitability’.

Ework and ebusiness in architecture, engineering and construction

788

4.1.2 Case study findings Reflecting on the cases, the critical mediating factors for collaboration with external teams were socializing to construct robust relations, maintaining cultural formalities, and protecting ‘know-how’. In the physical landscape, clients and consultants were almost exclusively excluded from organizations private places (e.g. Intranets, individual workstations, home working); this resulted in a preference to conduct collaborations in privileged places, such as private office meeting areas, dedicated meeting rooms or email for external teams. Typically organizations preferred to go to client, consultant team or exhibition places for faceto-face collaborations and did not provide shared privilege or private places in virtual environments. The only organization actively using extranets to generate a shared virtual environment was Splutterfish, who established a considerable part of their organization’s relationships through electronic ‘work environments’ such as on-line forums. None of the organizations where found to meaningfully employ public settings (urban amenities, hotel facilities, trade-show exhibitions, websites, and showrooms collaborations) for collaborations, except for marketing purposes and to establish early social relations with clients. Again the exception was the software development organization who had established privileged and public electronic settings (forums and IRCs) to engage their customers—their customers where also typically software developers. Suitability was seen as the key decision making factor in considering ICT tools. For example: the popularity to use personal mobile phones for direct and immediate feedback with team members who were not available face-to-face; email for transferring project information or coordination—followed-up with a phone call—evolving from fax and courier correspondence; or intranets (only for internal uses) for data management and office information tidiness. 4.2 The New Knowledge Environment 4.2.1 Summary The organization’s observed use of ICT tools and the environment in order to make collaborative work activities more effective are not being exploited; this reinforces Appliance Studio’s (Sharpe 2002) claim that knowledge workers engaged in team work perform significantly below their potentials because of the poor state of the ‘physical environment and tools with in it to get work done together.’ Critical to The New Knowledge Environment are four foundation concepts for understanding team behavior: ‘information affordance’, ‘projectbraiding’, ‘knowledge transformation’, and ‘distributed collaboration’. In summary, information affordance is the properties of an environment or artifact to facilitate a task-also referred to as an ‘appliances’. The most ubiquitous example of an appliance is paper, an information repository that is easily mobilized and written on. Project braiding is the continual coordination of individual tasks, roles and strands of information to the different activities of a team and to the overall goal of the project from start to finish. The objective is to fully exploit the expertise of all the members and fluidity of information. Important to project braiding is the social dynamics of a team.

Collaborative work practices in Turkey, five case studies

789

Third is knowledge transformation, this is the ability of an expert team to work in concert to generate new knowledge from discrete or multi-disciplinary sources and add value to an organizations knowledge capital. Knowledge transformation involves acquiring, organizing, producing, manipulating and synthesizing concrete and abstract information. The last principle, distributive collaboration, operates similar to the face-to-face collaborations, but is the ability to coordinate, exchange data or information and create new knowledge when teams are located in different places. The New Knowledge Environmenfs believes teams can be more effective given three potential in the ICT tool and the physical environment: ‘shared surfaces’, ‘persistent information’ and ‘extended presence’. It demands a shift in the traditional teamwork practices of information handling towards a practice of rich visual representations, democratic access to information and dynamic team manipulation-transformation of the teams information. 4.2.2 Case study findings The three potentials outlined were feeble in the observed organizations collaborative practices. When looking at the foundations of teamwork behavior I found the organizations’ behaviors underdeveloped. Although there were idiosyncratic exceptions, ICT tools and the physical environment was not seen as an opportunity to enable more effective collaborations, for example: whiteboards or flip-charts to note the important content in a collaboration, pin-up space which everyone could share the same vantage point of the information being presented, or cameras to easily record and distribute shared notes or meeting material in real time where atypical in collaborations. Interestingly the organizations dexterous in electronic project coordination tools or using the physical environment, even in a minimum way, to visualize project information were most effective in project braiding. Project braiding’s objective to maximize the potentials in other team members was understood enigmatically by the organizations and viewed as determined by a team social dynamics—organizations had difficulty conceptualizing how tools or the environment could foster this objective. The organizations observed infrequently engaged in knowledge transformation in their collaborations. Instead what was found is knowledge creation is generated by an organization’s ‘expert’ in the individual’s work arena and presented as solution to the team. The collaboration was then to coordinate the discrete solution into the greater team project, deliberate on appropriateness of the solution, or to make ref inements in the technical dimensions of the solution presented. Distributed collaborative practices utilized electronic tools. Electronic tool where limited to accessing shared information, project coordination scheduling, tracking project correspondence and better workflow management for internal groups, it was neither seen as a public or privileged place to transform information or opportunity maximize team member’s potentials. Important to note is all organizations impromptu or intimate (3–4 person) collaborations in the physical environment where not ‘readily’ (in the room) or ‘casually’ (not daunting) equipped with shared writing surface, pens and paper, internet access, a projector for an shared laptop, a place to post and re-organize information, a copier or a printer. This may clarify why the two modes to synthesize collaborative work were either

Ework and ebusiness in architecture, engineering and construction

790

verbal understanding or with meeting notes prepared by one participant and circulated to the other team members after the meeting concluded. 4.3 Embedding customers 4.3.1 Summary MIT Workplace Group partnered with Cambridge University (Joroff et al. 2004) to review how physical and IT infrastructure can foster the involvement of customers with the multiple objectives and processes of corporate research and development. The reports initial findings expand the bounds of workplace-making and explore propositions of how ‘experience’ of virtual and physical places can foster constructive collaborations. Their notion of ‘customer’ is defined as ‘any person who seeks to engage the enterprise, to serve its purposes, or who may benefit by connecting to activities…’ This could include the end-user, market analysts, individual who inform researchers about his needs, person who influences public opinion about its products and services, distributors with insights about demands of users, internal researchers who contributes or learns from colleagues, persons with direct feedback from customers, a researcher from a partner company or university, or even an organizational leader whose support and approval is critical for continual resources. The potential benefits of embedding the customer in an organization’s collaborative activities are to strengthen institutionalized learning, reduce risk by understanding customer preferences and needs, and can allow products to be developed jointly with customers and partners which engages customers interests and identification with the future products and services. 4.3.2 Case studyfin dings Each organization observed is considered to be on Turkey’s forefront in organizational innovations. The organizations observed who directly integrate their customer’s into their privileged work settings find this external stakeholder collaboration invaluable for their sustained development of services and product. Splutterfish has IRC rooms and on-line forum rooms for customers, partners and external colleagues. They noted the importance of collaborating with the external stakeholders allows direct market concerns and an immediate feedback-loop into their product development. InfoTRON was unique in that their customers typically became their clients and partners and therefore their engagement of external stakeholders has proliferate into a practice of institutionalized networking—clients and partners where a direct source of knowledge to identify future aspirations, trends and product needs in the market. All the other organizations are intuitively driven to consider this non-traditional knowledge creation collaborative practice with external stakeholders, but are insecure on how to set a course of action that does not render them vulnerable to their competitors. The organizations using the physical environment in traditional ‘customer’ engagements (meeting rooms, showrooms/demonstration areas and trade-show tours) do not capture this opportunity to embed customers in the organizations knowledge creation.

Collaborative work practices in Turkey, five case studies

791

5 NEXT STEPS Like abroad, Turkish organization’s decisions for workplace change are driven by economic and market conditions outlined by sustained competition advantage, continual renewal of products and services, and obtaining and retaining the best know-how on the market. Although the following suggestions for action may seem daunting to busy mangers, it is important to keep in mind small and thrifty, but effective steps can demonstrate new approaches. The SANE Report highlights how evaluation approaches, measurements and tools for workplace-making reflect current concerns and the way organizations and cultures think about work. Maybe more importantly evaluation techniques can ‘change the way society thinks about what is being measured’ (Harrison et al. 2002). In retrospect of conducting the case studies, I came to realize this insight is significant if we extend our considerations to the collecting, organizing and synthesizing dimensions of evaluation. Workplace evaluation and practices coming from Europe and North America assume substantive organizational management groups and human resources underpinning driving the collection, dissemination and implementation of the evaluation process. In Turkey, only in the past decades have business management and human resources education been available in higher education and hence these critical dimensions of workplace-making are relatively new in the context of Turkey. Regardless, knowledge work in any context requires us to think about work activities in a different way and suggests a practice of ‘situational awareness’ (Horgan 1999). Situated awareness asserts settings within which work takes place need to be described in ways that reflect their richness and their multi-layered complexity in order to detect ways in which they affect how individuals play out their lives and work. The most common theme amongst all the case studies is the dismal awareness of collaborative activities (concentration, duration, continuity, importance, predictability, formality, participants, geographic distribution, relationships needed, current relationships and confidentiality), collaborative tasks (collect, organize, transform, manipulate and distribute information), collaborative communication modes and mediums used to transfer, transform and create knowledge (verbal, shared writing surfaces, remote awareness technologies, rapid capture devices, or conferencing appliances); and where those collaborations occur (forums, chat rooms, on-line conferencing, break-out project rooms and hotel lounges). The first action plan is based on a concern given the current circumstances of meager situational awareness the workplace-making evaluation tools presented would be overwhelming without first becoming familiar with the fundamental ‘tool-kit’ of workplace-making. Grounding Turkish organizations in the fundamentals could be conducted through a series of focused workplace-making workshops. The first workshop would be an initial brainstorming of all the different activities the knowledge workers of the organization may undertake to get their work done; including all the places employed to carryout those activities. The facilitator of the workshops would suggest activities and places not mentioned by the participants to open their vocabulary and imaginations of where they work. The second workshop would focus on specific activities and preferences that occurred or they modified in their work activities and places when they became aware they where observing their practices to foster creativity in thinking or increase their potentials. This workshop could include a take-away questionnaire

Ework and ebusiness in architecture, engineering and construction

792

introducing tool preferences to track their behaviors and exercises to rehearse new work practices. The final workshop could be an opportunity to share stories amongst the participating organizations that enabled them to be more effective in their work objectives, reveal places and tools hindering their collaborations and identify a series of new collaborative practices in ‘knowledge transformation’ founded on workplace-making theories suitable for this activity. With this foundation of preliminary situational awareness behind them, these innovative organizations could meaningfully employ tools like SANE or Appliance Studio to suggest workplace approach on the most suitable choices of loosely coupled settings working in concert with available ICT tools. The second action is taken from MIT-Cambridge University proposal to leverage the physical and IT infrastructure to embed the customer into an enterprises knowledge creation. They suggest to launch ‘rehearsal’—let’s try activities—as alterations in the organizations existing physical environment. The notion is rehearsals, like any form of experimentation, are thrifty in their use of resources. And they reduce risk because they do not fail; they merely inform us about how to be better. For example, organizations can openly display the works team members for visitors to learn, explore and speculate on emerging products and services (strategy used by the MIT Media Lab), provide an interesting and highly readable history in waiting areas, or have a trained staff to encourage customers to explore new products, recombine products and suggest new products and services and ways of using them. If the organizations can institutionalize the learning from these exchanges and experiments, they will be adept to take a course of action to meaningfully integrate external stakeholders and immediate market feedback into their value creation infrastructure. REFERENCE Harrison, A., et al. 2002. Sustainable Accommodation for the New Economy (SANE): Final Space Environment Model. European Commission‘s 5th Framework Contract No. IST-2000–25257, D3, v 1.1. Horgen, T., et al. 1999. Excellence by Design: Transforming the Workplace and Work Practice. John Wiley & Sons, Inc.,NewYork. Joroff, M., et al. 2004. Embedding Customers in the R&D and Marketing Process of Research Parks. Report for Cambridge-MIT Institute. McKinsey Global Institute. 2003. Turkey: Making the Productivity and Growth Breakthrough. [http://www.mckinsey.com/knowledge/mgi/turkey/] Sharpe, B. 2002. The New Knowledge Environment. White-paper for Appliance Studio Ltd. [http://www.appliancestudio.com/publications/whitepapers.htm]

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Architecture for collaborative business process management—enabling dynamic collaboration S.Zang, O.Adam & A.Hofer Institutefor Information Systems (IWi) at the German Research Center for Artificial Intelligence, Saarbruecken, Germany C.Hammer, M.Jerrentrup & S.Leinenbach Interactive Software Solutions GmbH, Saarbruecken, Germany ABSTRACT: New forms of cooperation like collaborative business scenarios require a deep but flexible integration of enterprises. To manage interorganizational business processes existing concepts for business process management need to be adapted and extended. In this paper an architecture is presented, that shows how cross-enterprise processes can be planned, implemented and controlled. The architecture is based on the differentiation of global knowledge within the network and local knowledge of each participating company. Another important part of it is the process life-cycle model that serves as a guideline for the processoriented setting-up and operation of cooperations. By the use of graphic representations of BPM-models and intuitive metaphor-based modelgeneration and -visualization tools a broad acceptance for the interorganizational BPM-effort within the partners can be achieved.

1 INNOVATION THROUGH COLLABORATIVE BUSINESS The growing importance of cooperation in the construction industry is a result of globalization in combination with the disappearance of political borders and technological changes caused by the Internet (Scheer et al. 2000) (Naisbitt 1986). Thus, enterprises have to react to the raised innovation pressure and are often forced to align their processes in order to be able to collaborate on a global scale. The borderless enterprise has been the subject of scientific discussion for years (Picot et al. 1997) and the collaborative production of goods and services has been established as a crucial factor in the consciousness of economic entities. The opening of the organizations’ borders is no longer regarded as a necessary evil, but rather as a chance with strategic importance (Kanter 1991). The additional effort caused by the implementation and running of the network has to be overcompensated by the addedvalue. To facilitate this enterprises have to build up new forms of cooperation characterized by a flexible and low-cost feasibility in order to be permanently successful on largely saturated markets. Current approaches that address solutions to specific problems of dynamically interacting organizations are summarized under the term “Business Integration”; the field

Ework and ebusiness in architecture, engineering and construction

794

of investigation is referred to as “Collaborative Business (C-Business)” (Scheer et al. 2002). C-Business describes the Internet-based interlinked collaboration of all participants in an added-value network—from the raw material supplier to the endconsumer (Scheer et al. 2003a). It allows a comprehensive information exchange not only between employees but also between departments and even between enterprises and encourages creative cooperations at all levels. As first case-studies show, the increase in added-value is out of proportion to the amount of participants in the network. Unlike former concepts, as e.g. E-Procurement, which focused only on small parts of the value chain, C-Business incorporates all stages of added value and business processes. Measures for Business Integration incorporate all relevant business partners into the system; by doing so they become part of the entire collaborative process (Scheer et al. 2003b). While the technological implementation on the one hand and the business model lifecycle on the other hand have already been intensively researched, too little consideration is given to the interconnecting business management concepts. A rethinking from the pure technology-driven implementation or profit-driven business model discussion to an integrated view that spans from the conceptual level to the system blueprint is needed. On the conceptual view business processes have proven to be the ideal design item in conjunction with the use of graphical methods. These models can then be transformed into IT-based specifications. With the use of open, standardized technologies, such as web services, they enable Business Process Automation, i.e. the automatic negotiation of process interfaces. For a detailed and systematic analysis and redesign of interorganizational processes, enterprises need an architecture that offers a set of integrated methods from the business concept level up to the implementation into IT-systems. The appropriate graphic representation of these contents is of great importance in order to support the exchange of ideas and the reconciliation of interests between the different recipients within the network. Finding consent and decision-making between the different stakeholders is considerably facilitated by a general methodology; it encompasses not only the common conception of a collaborative business process but also the system-side implementation in an existing IT application landscape. Besides, more and more workflow-aware application systems are used in mission-critical environments, e.g. as an extension of ERP-systems. Thus the main challenge concerning technology is the open implementation and interoperability of these process-sensitive applications in order to integrate preceding and following process steps dynamically (zur Muehlen et al. 2003). To achieve a truly flexible integration and interoperability, standards like ebXML, RosettaNet, GAEB have to be consolidated within the architecture to ensure a common procedure within the business network. For these purposes a proposal for the architecture for collaborative process business management is developed in this paper. Furthermore collaborative modeling tools already used in the ArKoS project show are presented to demonstrate how theory can be put into practice.

Architecture for collaborative business process management

795

2 ARCHITECTURE Compared to traditional business processes, the complexity of interorganizational processes rises considerably as a result of the numerous possibilities of interaction as well as the strategic, structural and cultural differences between the partners. Coordinating the business partners turns out to be more difficult, especially because of the differing objectives and the lack of inherent organizational arrangements and behavior guidelines as they exist within an enterprise (Scheer et al. 2000). The allocation of performances and resources of the business partners, the determination of responsibilities for material and financial exchange relationships, as well as the information and data exchange over interfaces have to be planned, arranged and “lived” together. Thus the demands on Business Process Management (BPM) increase. Existing BPM methods and phase models are used as a foundation in the architecture presented here, which had to be adapted to the specifications of collaborative scenarios. Especially because of its completeness of vision and its proven practicability, both in the scientific and the economic context, the “ARIS House” (Scheer 2002) is accepted as a generic framework for business process management and serves as a basis for further considerations. The ARIS House describes a business process, assigning equal importance to the questions of organization, functionality and the required documentation. First, it isolates these questions for separate treatment, in order to reduce the complexity of the description field, but then all the relationships are restored using the Control View introduced for this purpose. Below, the Architecture for C-Business Process Management is represented in a threetier framework that is connected through control loops, following the concept of business process excellence of Scheer (Scheer & Borowsky 1999), which consists of a model to track a complete life-cycle model of business process management, including modeling, real-time control and monitoring of business processes. The first layer focuses on the collaboration strategy. In the centre of the second layer, the “C-Business process engineering”, there are design, optimization and controlling of both enterprise spanning and internal processes. The third layer, “C-Business execution”, deals with the (operational) implementation of business processes in value-added networks as well as their support through information and communication technologies. The structure of the layer model is clarified in Figure 1. 2.1 Views on business process models As described above, the framework is based on the ARIS House and divides it into a vertical axis of global knowledge of all collaboration partners and a horizontal axis of local knowledge of the single participants (cf. Fig. 2). The organisation view and the output view are global knowledge because a goal-oriented collaboration is impossible without them. At the time the interaction occurs between two partners, local knowledge is shared (bilaterally) between the partners, i.e. additional information, like data structures and semantics are exchanged. Updates of the local knowledge do not influence the network as

Ework and ebusiness in architecture, engineering and construction

796

network knowledge has to be available for all partners. This information is stored in the description of the interfaces in the Process Module Chain (cf. section 2.4). Changes in the global network knowledge and as a consequence changes in the output and organization

Figure 1. Architecture for Collaborative Business Process Management.

Figure 2. Global and local knowledge in value-added networks. view have to be accessible to all partners immediately, for example if a company leaves the network or if a product or service is no longer available within the network. Global and local knowledge merge gradually in the step-by-step development of CBusiness process engineering. Following this distinction between global and local

Architecture for collaborative business process management

797

knowledge, a language is needed for the exchange of these knowledge fragments. Because the necessary detail functions and data schemes of the respective enterprise are determined in the data and the fUnction view, these are treated from a micro perspective. They are characterized by an intensive internal interdependence, whereas externally a standardized encapsulation has to be provided. Interfaces of the data and function views to other network participants become visible in the process view in form of attribute correlations to process modules and concern the technological field of the cooperation during the realisation much more intensely than the conceptual one. This enables the generation of public and private (enterprise-internal) views and levels of detail for management, process owner and IT-experts out of a C-Business model. 2.2 Visualisation of business process models Discussing business processes means discussing abstract and mental formations as well. Normally the process-owner has a clear understanding of what he is discussing. But if the process has to be communicated to co-workers or even to partners within the network, the notional construct has to be visualized. This task is called process visualization. In general visualization can be defined as an activity to illustrate issues to a viewer. It is an effort to refine the mental representation of a process by using available media like images, texts or animations. In order to extract relevant information out of visualization a special visualization method is required. This method should appropriately convert abstract information into graphical information. The value of information not only depends on the amount of visualized data but especially on the possibility to easily extract relevant information from the represented data. A special challenge of process visualization is mastering the scope of interpretation. To exemplify this problem the common idiom “a picture is worth a thousand words” can be used. The statement itself might be correct but the thousand words probably differ depending on the respective viewer. The main concern of process visualization is to achieve a common understanding of collaborative processes among all persons involved in the business process. This means all addressees have to be integrated although each of them has a different focus. 2.3 C-Business strategy Enterprise spanning business processes are not planned in detail at the strategic level but designed as concentrated, high-level process modules. Thus, they combine the public knowledge about the collaborative processes that is shared by all participants. Business process models for collaborative scenarios at the strategic level no longer act on the assumption of a chronological view of the process alone, but more on a role-based process model to discover new value-added potentials. C-Business scenario-diagrams that are used e.g. by SAP Ltd. for the description of my-SAP.com collaboration scenarios, aim at the representation of the cooperation of different enterprises and participants by means of an easily understandable method and the documentation of the value-added potentials resulting from it (Hack 2000). The responsibility for each process step, indicated by swimlanes, is of central importance to the determination of the scenario. This method is integrated into the ARIS concept and combined with methods of

Ework and ebusiness in architecture, engineering and construction

798

(classical) business process and data modeling used at the C-Business Process Engineering layer. The question of core competences in the enterprises is directly associated with the question which processes remain in the enterprise and which are supposed to be assigned to partner enterprises or collaboratively operated (Jost & Scheer 2002). 2.4 C-Business process engineering On this layer each partner considers their part in the inter-enterprise process. Each party models its own internal processes. The event-driven process chain (EPC) is used for the design of the process flow within an enterprise. A possibility to reduce complexity and to focus on special aspects is the usage of different views like the data view, the organizational view, the function view or the output view. The ARIS House delivers all necessary methods for this step. To generate a public view the EPC had to be enhanced by a new construct, the interface, which is marked by the letter “I” and stands for the interfaces that link private process models within the collaborative scenario. For the collaborating partners only the data at the interfaces, that is the input respectively output data of the single process modules (resp. EPC), are relevant for the realization of the collaboration. Thus it is guaranteed that the enterprise-owned EPC is only internally visible. Fuelled by the global need for organizational and output information, parts of the local business process models can then be visualized by an appropriate graphical method in order to gain knowledge of the common processes and to reduce the complexity of integrating the participating organizational units into one virtual unit. The Process Module Chain clearly and understandably represents the collaborative processes (Grieble et al. 2002a). It consists of single process modules or components, in which again more detailed EPCs, that contain the local processes, are lodged (Grieble et al. 2002b). Process Module Chains are particularly suited for the illustration of collaborative process flows because the single process modules form a logically terminated unit and the interfaces, located between the single modules, contain input data for the following modules. The collaboration partners have to continuously compare the result of the implementation with their goals and adjust deviations. Hitherto the management has obtained its knowledge about the company’s success from figures of the past, e.g. cashflow, trading volume or profit made. The causes for fluctuations, requiring immediate counter measures, are not discernible. Until the problem is recognized, valuable time has elapsed. Therefore new measurement categories, which allow a reliable and contemporary evaluation of the process efficiency, are required. The information needed cannot be extracted from the record and transaction oriented applications alone. Key performance-indicators must be defined based on records, log-files, time stamps etc. These can be measured and analysed by means of intelligent tools (Jost & Scheer 2002). The controlling function is a must when there is a high degree of uncertainty as with C-Business projects. The management can permanently control the implementation of the strategic collaboration configuration and promptly evaluate whether the expected addedvalue potentials have been reached.

Architecture for collaborative business process management

799

2.4.1 Tool-based, automatic generation of process models The usage of views as described before should be supported effectively by a visualization system. In general many different kinds of organizational units or external consultants are involved in the modeling task. In the case of interorganizational process management the amount of addressees increases immensely so that a standardization of the modeling task and a common understanding of the process become critical to success. To face this challenge the use of tools is strongly recommended. A newer approach, which is followed in the ArKoS project, is to record the process while reenacting it. This can be achieved with the aid of tools, e.g. the

Figure 3. Automatic generation of a process model. INTERACTIVE Process ModelerVR from Interactive Software Solutions (cf. Fig. 3), which provides an intuitive communication platform available within the intranet of an enterprise to record business processes interactively and in a decentralized way. In particular the personnel functionally responsible for the process describe the business processes by playing them through within a three-dimensional (or two-dimensional) virtual visualization of the enterprise. Thereby they do not depend on the support of method experts. After having logged-on to the system the employees describe the relevant (partial) processes by communicating with other employees and by interacting with close-toreality graphical objects, which represent the tools used or the objects transformed along the business processes. The virtual representation of the reality is adapted individually to the respective enterprise, so that the processes can be conceived and worked on as intuitively as possible. Thereby the extent of visualization reaches from simple two-

Ework and ebusiness in architecture, engineering and construction

800

dimensional metaphors for the immediate working space and processed objects and/or tools up to a three-dimensional Virtual Reality representation of the enterprise. The recording of the activities of the respective employee in the virtual working environment is done by using the INTERACTIVE Process ModelerVR. Semi-formal process models needed for the data processing-supported analysis and evaluation can be produced by the click of a button. The automatically provided process models are based on the method of the extended event-driven process chains (eEPC) and can be handed over to a process modeling repository, for example the one of the ARIS Toolset, to process the model. By playing through the processes no further knowledge of modelling methods is required and so the process recording can be accomplished by the functionally responsible employees. In this way several advantages can be achieved: information loss due to communication problems between employees as knowledge carriers and method experts as knowledge modellers are reduced to a minimum. In addition,

Figure 4. Intuitive process visualization in 3D. modelling errors resulting from formalisation of the surveyed process knowledge by method experts are avoided. By the intuitive representation weak points and opportunity of improvement can be identified and used for the construction of optimized target processes. Furthermore, expensive method training courses and the use of modelling experts can be avoided to a large extent by renouncing the use of abstract display elements, which are used for example in the context of formal process modelling methods.

Architecture for collaborative business process management

801

2.4.2 Tool-based communication of process models Within the process execution phase the implementation of target processes, the evaluation of the existing processes and the permanent optimization of processes require an adequate visualization of the processes in order to establish a common understanding of the processes among all persons involved. This holds especially true for interorganizational processes. Specialized divisions’ employees with knowledge about the operations often take a rather passive role. With the help of understandable and intuitive visualization tools, the methodical access to the process models is simplified and thus the results of the business process management initiative can be transferred to each employee. This is particularly important in order to make employees participate in each phase of the BPM-effort. In order to achieve the demanded participation by employees in validation and discussion of the process concepts produced in reorganization projects the business processes are visualized close-to-reality. Modeling errors can be recognized and eliminated easier and faster on a much broader basis. The new form of business process visualization can serve to reach a quality improvement of conventional semi-formal business process modeling methods. For this intuitive and employee integrating visualization the tool INTERACTIVE Process VisualizerVR from INTERACTIVE Software Solutions is adapted here (cf. Fig. 4).

Figure 5. Collaborative Business Process Management life-cycle.

Ework and ebusiness in architecture, engineering and construction

802

When the optimization should go across corporate-frontiers the challenge gets more demanding, because of the higher complexity, as described in section 2. There the distributed modeling approach combined with the usage of close-toreality metaphors can achieve an immense boost for the success of business process management within distributed modeling environments. 2.5 C-Business process execution Instead of closed systems that have been used so far, C-Business requires the integration of different applications. Component based architectures that are process-driven and rely on fully developed standards and interfaces can be seen as a state-of-the-art approach to overcome these problems (McMichael 2003). Process-driven emphasizes the importance of the process models created on the preliminary layer. At the execution layer these models are used for process orchestration. Orchestration in this context describes the composition of business objects in a process flow. In detail, it defines the complex interaction between business objects, including the business logic and execution order of the interactions. Without orchestrating business objects the overall context between the single process steps would be lost. So far these semantics are stored in the isolated process descriptions and models (business process knowledge) on a conceptual level. However, the automation of crossorganizational business processes must be based on a system that allows the transformation of semantic into formal models. With the use of XML the technological basis for interoperability has been established, the interoperability between the semantic business process definitions however is still missing. EfForts like BPMI’s Business Process Modeling Language (BPML) promise standardization for the management of inter-organizational business processes that involve different applications, departments and business partners (Arkin 2002). This standard, which is based on XML, complements existing B2B protocols like RosettaNet, Biz-Talk and ebXML. On the one hand BPML acts as an intermediary between business process modeling tools and IT. On the other hand BPML enables the interoperability between model-ing tools. Besides, a wide acceptance of the Business Process Execution Language for Web Services (BPEL4WS) by BEA, IBM, and Microsoft as well as the newly finalized specification of the Web Services Choreography Interface (WSC I) mainly driven by BEA, Intalio, SAP and Sun show the importance of such standardization efforts for interoperability (Shapiro 2001). While BPML is seen as more conceptually-oriented, the latter two focus on the transformation into the system-level by or orchestrating web services. 3 COLLABORATIVE BUSINESS PROCESS MANAGEMENT LIFECYCLE The life-cycle-model presented in this section serves as a manual for the process-oriented setting-up and operation of cooperations. Using a consistent phase model and standardized modeling methods increases transparency and structuring of cooperations and creates a basis for comimmication between participants; these include the

Architecture for collaborative business process management

803

management who lay down strategies as; those responsible for the processes in the departments and IT-experts who integrate the different application systems. Despite the increased complexity of a network process in comparison to internal processes, those involved have to adapt to constantly occurring changes in a fast and flexible way. The life-cycle-model presented above is a fusion of classic phase-models with lifecycle-models of virtual enterprises (Mertens & Faisst 1995). The resulting dynamic model is consistent with the structure-oriented architecture of Collaborative Business Process Management and follows the classification of the view model into global and local knowledge. It represents a cyclical approach. Protecting internal know-how is of paramount importance to the network participants, even though the business process knowledge has to be used jointly. From this perspective, global and local knowledge finds itself, regarding the processes, in internal (private) and enterprise-spanning (public) process representations. 3.1 Pre-phase and reconfiguration Prior to the use of the architecture is the awareness of one or more enterprises that they can profit by collaboration with complementary core competence partners. Afterwards, in the formation phase, mostly referred to initiation and agreement of the enterprise network, the collaboration partners are determined by the shared goals of the collaboration and the aspired win-win situation of all partners. In this model, it is assumed, that a set of potential network participants is given. The decision if and with which enterprises out of the basic set a C-Business scenario should be implemented is taken by every single enterprise individually and rationally; for this reason it depends highly on the expected economical profit of the individual partner. After conducting the cooperation the companies regroup or split and reconfigurate themselves. The life-cycle returns to its starting position “awareness”. 3.2 Main-phases In the next step, the joint aims of the collaboration have to be defined as synthesis of the individual aims. To facilitate the collaborative service production, graphic methods, like product models, are used in this stage for the determination of a common service bundle. They simplify and put the often implicit objectives into concrete terms. In addition to the characteristic features of a service or a product over its entire life-cycle, the organizational units participating in the service production are contained in a product model (Genderka 1995). By means of product trees enterprises can conceal detailed service descriptions in an internal view that puts special focus on the organizational aspects of the product offered by the partners. In an external view they just provide the information required for the configuration of the common service bundle in form of product bundle models (Scheer et al. 2004). After the basic parameters of the collaboration are determined the procedures and the interactions are planned in more detail at the engineering layer. Having completed the strategy finding, in the next step the local (private) processes of each partner are adapted and the processes regarding the collaboration (public processes)

Ework and ebusiness in architecture, engineering and construction

804

are generated as an aggregation of all internal views of the network partners. The business processes will be designed by using reference models based on best practice and theoretical considerations. Like design patterns that show a generic solution of the network architecture on a technical basis reference models are used to show possible solutions for a process description on the conceptual level. Each partner considers their part in the inter-enterprise process. Starting with process modelling and optimisation over process controlling up to implementation, the processes involved are aligned with the requirements of the collaborative scenario agreed on at the strategic level. In order to automate inter-organizational processes the conceptual models are transformed into formal models that are used as configuration data for the orchestration of business objects. The applications of the partners have to communicate bilaterally to negotiate the interface specifications based on the formal models, defined in the repository. The local knowledge is generated by this negotiation for a certain situation. After this collaboration task has ended no updates of configuration changes etc. are reported to any other party except at the time when a new direct interaction occurs. In this context multi-agent systems offer a solution to achieve an automated or at least semiautomated interface-configuration (Blake 2003, Denti et al. 2003). 4 TOWARDS AN INTUITIVE COLLABORATION MANAGEMENT The described conceptual design of inter-enterprise business processes is currently elaborated in the research project “Architecture for Collaborative Scenarios (ArKoS)”, finded by the German Federal Ministry of Education and Research (BMBF). As a proof of concept the presented methods will be implemented in a software prototype and will be used in real-life showcases. ArKoS is one project in a research effort conducted by the Institute for Information Systems to improve business process management across organizations. ArKoS uses e.g. the results of the successfully accomplished project InfoCitizen. The project, funded by the European Commission under the 5th Research Framework Program, aimed at creating a pan-European Information Architecture for European PAs as well as to develop specific information technology that supports this architecture and ensures a seamless information exchange between public administrations on a pan-European level. Moreover, with this solution the EPAs are enabled to provide transparent and integrated public services for their customers, i.e. citizens and businesses. Eleven organizations within five different EU-countries (Germany, Greece, Italy, Portugal, Spain) worked together for two years to succeed in the challenge of panEuropean interoperability. A prototype of an agent-based inter-operability platform with a service repository as described in the conceptual part of this article was developed. The business processes are stored in an XML-representation and the agent platform invokes dynamically the service offers which are implemented as distributed web services. On this basis a broad and intense dissemination and deployment impact is conducted. The generic methods developed herein will enable ACE enterprises to seamlessly integrate partners, building owners and subcontractors in collaboration scenarios on the technology but especially on the conceptual level. Each user will experience intuitively understandable business process design, planning and controlling, so that cooperation

Architecture for collaborative business process management

805

procedures will be very clear. Userspecific views on the Business Process Models will enable new user groups to use BP models. Moreover ICT can support actively business process management by checking, verifying or even automatically negotiating consistency and interoperability of models. REFERENCES Arkin, A. 2002. Business Process Modeling Language. Working Draft. Blake, M.B. 2003. Coordinating multiple agents for workflow-oriented process orchestration. http://www.cs.georgetown.edu/~blakeb/pubs/blake_ISEB2003.pdf. Denti, E., Ricci, A. & Rubino, R. 2003. Integrating and orchestrating services upon a MAS coordination infrastructure. http://www.ai.univie.ac.at/~paolo/conf/ESAW03/presentations/E0011.ppt. Jost, W. & Scheer, A.-W. 2002. Geschäftsprozessmanagement:Kernaufgabe einer jeden Unternehmensorganisation. In: Jost, W, Scheer, A.-W. (eds), ARIS in der Praxis: Gestaltung, Implementierung und Optimierung von Geschäftsprozessen. 33–4, 38, 42 et seqq. Berlin: Springer. Genderka, M. 1995. Objektorientierte Methode zur Entwicklung von Produktmodellen als Basis Integrierter Ingenieursysteme. 13. Aachen: Shaker. Grieble, O., Klein, R. & Scheer, A.-W. 2002a. Modellbasiertes Dienstleistungsmanagement. In: Scheer, A.-W. (ed.), Veröffentlichungen des Instituts für Wirtschaftsinformatik. No. 171, Saarbriicken, 22. Hack, S. 2000. Collaborative Business Scenarios—Wertschöpfung in der Internetökonomie. In: Scheer, A.-W. (ed.), E-Business—Wer geht? Wer bleibt? Wer kommt?. 21. Saarbrücker Arbeitstagung für Industrie, Dienstleistung und Verwaltung., 85–100, 88 et seqq. Heidelberg: Physica-Verlag. Kanter, R.M. 1991. Transcending Business Boundaries: 12,000 World Managers View Change. In: Harvard Business Review 69 (1991) 3, 151–164. McMichael, C. 2003. Business process integration may eclipse EDI, EAI. In: HP Chronicle 17 (2003) 6, 1, 6. Mertens, P. & Faisst, W. 1995. Virtuelle Unternehmen—eine Organisationsstruktur für die Zukunft?. In: Technologie & Management 44 (1995), 61–68. Naisbitt, J.: Megatrends 1986. Ten New Directions Transforming Our Lives. 6th edn., New York: Warner Books. Picot, A., Wigand, R. & Reichwald, R. 1997. Information, Organization and Management— Expanding Markets and Corporate Boundaries. Chichester: Wiley. Scheer, A.-W. & Borowsky, R. 1999. Supply Chain Management—die Antwort auf neue Logistikanforderungen. In: Kopfer, H., Bierwirth, C. (eds), Logistik Management—Intelligente I+K Technologien. 3–14,. Berlin: Springer. Scheer, A.-W., Erbach, F. & Thomas, O. 2000. E-Business—Wer geht? Wer bleibt? Wer kommt?. In: Scheer, A.-W. (ed.), E-Business—Wer geht? Wer bleibt? Wer kommt?. 21. Saarbriicker Arbeitstagung 2000 für Industrie, Dienstleistung und Verwaltung. 3–45. Heidelberg: PhysicaVerlag. Scheer, A.-W., Beinhauer, M. & Habermann, F. 2000. Integrierte E-Prozessmodellierung. In: Industrie Management 16 (2000) 3, 19–26, 20 et seqq. Scheer, A.-W. 2002. ARIS—Vom Geschaftsprozess zum Anwendungssystem. 4th edn. Berlin: Springer. Scheer, A.-W., Grieble, O., Hans, S. & Zang, S. 2002. Geschäftsprozessmanagement—The 2nd wave. In:

Ework and ebusiness in architecture, engineering and construction

806

Scheer, A.-W. (ed.), IM Information Management & Consulting 17 (2002) Sonderausgabe, 9–15, 10 et seq. Scheer, A.-W., Grieble O. & Zang, S. 2003a. Collaborative Business Management. In: Kersten, W. (ed.), ECollaboration—Prozessoptimierung in der Wertschöpfungskette. 30 et seq.. Wiesbaden: Deutscher Universitüts-Verlag. Scheer, A.-W., Feld, T. & Zang, S. 2003b. Vitamin C fiir Unternehmen—Collaborative Business. In: Küting, K., Noack, Chr. (eds), Der grofie BWL-Führer. Die 50 wichtigsten Strategien und Instrumente zur Unternehmensfühmng. pp. 123–129, 124 et seq.. Frankfurt: F.A.Z.-Institut. Scheer, A.-W., Herrmann, K. & Klein, R. 2004. Modellgestütztes Service Engineering— Entwicklung und Design neuer Dienstleistungen. In: Bruhn, M., Stauss, B.: Dienstleistungsinnovationen: Dienstleistungsmanagement Jahrbuch 2004. Wiesbaden: Gabler, in print. Shapiro, R. 2001. A Comparison of XPDL, BPML and BPEL4WS: Cape Visions. Rough Draft, 1– 17. zur Muehlen, M., Nickerson, J.V. & Stohr, E.A. 2003. Process Integration—From Workflow Models to Web Service Choreography. Istanbul 2003 Euro/Informs, http://www.istanbul2003.org/main.html.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Comprehensive information exchange for the construction industry J.Díaz Area of Computer Science in AEC, University of Applied Sciences Giessen-Friedberg, Germany ABSTRACT: In the building and construction industry a change can be determined from a sub structured to a more holistic enterprise-spreading information exchange. Co-operation between companies, consultants, and authorities by digital information ex-change becomes a strategic success factor. Solutions, which cover all stages of the value creation chain, such as e-tendering, cost estimation, calculation, and production must be anytime accessible and hardware independent. While the basic conditions of IT-infrastructure (digital networks) are today fully sufficient, the compatibility between the systems and the information to be exchanged represent the largest problem. The main problem is in the range of different systems and various information domains. Transformations and adjustments of the exchanged information still cost nearly 40% of engineering time. Efficient information exchanges require an universal exchange format, which makes the existing systems compatible. This paper describes the German approach for a holistic information exchange in the building and construction industry.

1 INTRODUCTION The construction industry has a very heterogeneous IT landscape, which makes an economical integration of software systems more difficult. The integration is prevented by the existence of different software systems and their proprietary data standards. Therefore the necessity of a standard for information exchange within the construction processes is ever more obvious. These construction processes begin for example, with the first request for bids by the project owner that could end with the distribution of construction material and elements from the supplier to the contractor. Between the construction processes there usually lies a multiplicity of individual activities, which must be accomplished frequently by different project participants by means of different software systems. According to these fragmented processes often a complex information exchange with multiple data input follows, which increases information errors and time delays (Kalantari, B., Diaz, J. 2001). The infrastructure of the internet is an ideal platform for the integration of prqject information in the construction industry where heterogeneous partners are working together. By the possibilities of an online co-operation tool in the tendering and bidding procedure, and material procurement, a large cost-reduction potential is achievable.

Ework and ebusiness in architecture, engineering and construction

808

Using a comprehensive information exchange the transparency and the quality of the construction processes increases. Simultaneously the costs decrease. Generally the tendering and bidding procedure is divided into three business domains: planning, execution and supplying (see fig. 1). Furthermore there are two main sectors within the tendering and bidding procedure: e-commerce and project communication. On one hand the task of the GAEB project was to develop an efficient method of collaboration. On the other hand it would also develop an enterprise wide exchange of information within the tendering and bidding procedure (Diaz, J. 2002).

Figure 1. XML Integration in the Domains of the Construction Industry. 2 GAEB (JOINT COMMITTEE FOR IT IN THE CONSTRUCTION INDUSTRY) A holistic solution for the purpose of information exchange is offered by the German group GAEB (Joint Committee on IT in the Construction Industry) (http://www.gaeb.de/). GAEB offers a distributed approach, which makes the information exchange by a common standard on basis of XML technology possible and helps to solve existing communication problems. The developed standard and information structure defines the holistic information exchange format and is based on the XML technology. The following three points describe the decision of using XML as an overall standard: (Kalantari, B., Schaffler, H., Diaz, J. 2000) • separation of structure, content, and layout in the documents, • compatibility, flexibility and internationality (UNICODE) and • platform independence In the following the overall holistic information exchange format will be presented.

Comprehensive information exchange for the construction industry

809

The Joint Committee on Information Technology in the Construction Industry (GAEB) promotes the use of data processing in building and construction. Public and private owners, architects, engineers, the construction business, suppliers, research institutions, and construction software companies are all represented by their own federations or professional associations in the GAEB. The GAEB establishes the preconditions necessary for the use of integrated information exchange in the execution of construction work and supports all partners involved in the building and construction process to use this open standard, which serves as a specification for the creation of different interface software. The current GAEB standard is called: GAEB DA2000-xml. The main objective of the GAEB DA2000-xml project is to support the building and construction industry to cooperate faster, cheaper, and more effective, by using the new xml-based technology, that is specifically tailored to the needs of the building and construction (BC) industry. Although internet capabilities form the ideal low-cost communication platform for the BC industry. In BC practice internet is currently only used in a very limited way. The most important reasons for the limited internet use in BC are: insufficient security, low bandwidth, unsatisfying possibilities for structuring specific information. The current internet language XHTML is too simple, and too insufficient. It is also unstructured to support BC communication requirements, due to the fact, that only limited data exchange is supported. GAEB has developed a specific eXtensible Mark-up Language (GAEB DA2000-xml), that covers all needs mentioned above by providing the right information infrastructure for this industry. 2.1 Overview of information exchange for bid call, award and billing processes The bid call, award and billing (BAB) process is an important part of the construction process, which for example regulate the first request for bids by the project owner. It ends with the distribution of construction material and elements from the supplier to the contractor and the billing of the services. For a holistic and economical information exchange in the BAB process, the various BC partners using heterogeneous software systems must be integrated based on the above mentioned standard. This is the most important requirement for an optimal communication and value creation in the building and construction industry. The BAB process for construction tasks also requires that a common set of rules are defined and are available for free. It is required that the generated information (specification, bill of quantities/materials, product descriptions, bills etc.) must be exchanged in a digital way and therefore they must be well classified, and well structured (Diaz, J., 2002). Such a course of action has following advantages: • It makes information available and reusable on a digital basis. • It reduces working time managing the information. • It optimizes workflow processes. • It reduces input errors because there is no need to reenter the data. The diagram below illustrates the parties involved in BAB processes.

Ework and ebusiness in architecture, engineering and construction

810

2.2 Information flow using GAEB-XML The GAEB specifies different document types to cover the communication needs between the different partners. Each document is assigned to a so called data exchange phase, e.g. the data exchange phase D83 represents the call for bids (see fig. 3). During

Figure 2. Partners involved in the BAB process. each of this phase’s additional information like the description of work items, prices etc., are incorporated into the data structure. The specific information must be available in the assigned construction sequence. Therefore the construction sequences form the basis for the data exchange phases, which contain logical objects in which elements comprising keywords and their values are embedded. It makes no difference whether the information is exchanged between sophisticated cost estimating systems, or cost calculation systems, or is used for viewing purposes on site. The following figure demonstrates all partners and specified document types (data exchange phases). The figure shows all possible scenarios of information exchange between the BC partners. The partners have to use for each data exchange phase the specific document type for co-operation. This is based on public building law. The most important data exchange documents in the GAEB standard are defined in the so called 80’s and 90’s phases. The phases D80-D89 are responsible for the co-operation on basis of bills of quantities/materials and the phases D90-D99 for procuring processes (e.g. ordering products). All these documents are specified with the platform independent and programming language independent XML technology. The XML technology makes the implementation of BAB software systems easy and economical. For the definition of different document types the newest XML schema technology is used, which enables on a much better way the definition of data ranges, exceptions etc.

Comprehensive information exchange for the construction industry

811

2.3 Explanation of the GAEB-XML procedure for inquiries/orders The standardization of digital data exchange between contractors and suppliers based on XML plays a very important role in the upcoming B2B environment.

Figure 3. Holistic Information Flow in the GAEB DA2000-XML Standard. Project information like bill of quantities/materials is used for data exchange between construction companies and manufacturer/dealer/supplier. When preparing a bid, the contractor sends the bill of quantities/materials to the manufacturer/dealer/supplier as a price inquiry. The manufacturer/dealer/supplier then sends a quotation to the contractor. This information is modified by the construction company, and finally incorporated in the contractor’s estimate and used in the bid. The definition of a standard for material procurement in the building and construction industry is one of the most important parts in this project, because all stages of the procurement process must be considered. Therefore different xml schemas are adopted like classified schemas and product catalog schemas. These standardization is essential, because only then BAB systems can exchange successfully digital information covering the distinguish aspects. The standard has also to consider various hardware and software platforms and has to provide a common language for construction information exchange. However, the real problem is the heterogeneity and openness of the exchanged content as is the case of bills of quantities/materials. There are at least two levels at which this heterogeneity arises: • at the level of product catalogs structures, • at the level of product classifications.

Ework and ebusiness in architecture, engineering and construction

812

Structuring and standardizing the product descriptions is a significant challenge for BAB processes. It helps customers to find efficiently the products they are looking for. There are different schemas and standards for product classifications and product catalogs, which are important for the BC industry. In the following are the most important standardizations addressed (Leukel, J., Schmitz, V, Dorloff, F.-D., 2002). 3 STANDARDS FOR PRODUCT CLASSIFICATIONS AND PRODUCT CATALOGS 3.1 A. The BMEcat format The BMEcat-format (http://www.bmecat.org/) was developed with the objective of standardizing and simplifying the exchange of product data catalogs, that are used between suppliers and purchasing organizations. In the basic model, a supplier compiles a catalogue in electronic form which complies with the BMEcat standard. The Bundesverband Materialwirtschaft, Einkauf und Logistik e. V (BME) [Federal Association for Material Management, Purchasing and Logistics] in Frankfurt/Main is responsible for the BMEcat standard. Many renowned companies have taken a very active part in this initiative. These

Figure 4. Necessary Steps for Ordering Processes in GAEB. include Alcatel, American Express, Audi, Bayer, BMW, C@Content, DaimlerChrysler, Deutsche Bahn, Deutsche Telekom, DLR, e-pro solutions, Frankfurt Intern. Airport,

Comprehensive information exchange for the construction industry

813

GZS, InfraServ Hochst, Lufthansa, Mannesmann, Philips, PreussenElektra, Ruhrgas, Siemens, VEBA and VISA (http://www.bmecad.de/). 3.2 The eCl@ss standard Each supplier may use different structures and vocabularies to describe their products. This may not cause a problem for a one-to-one relationship where the buyer may get use to the private terminology of his supplier. BAB market places that enable n-m commerce cannot rely on such an assumption. They must classify all products according to a standard classification schema that help buyers and suppliers in communicating their product information. eCl@ss is a widely used classification schema (http://www.eclass.org/). The following picture shows the necessary steps for the specification of information exchange during the material order in GAEB. There are 3 steps within three different domains: • physical data layer • categorization layer • cataloging layer

4 INTERNET BASED BAB PROCESSES USING GAEB-XML Internet and Web technologies start to penetrate many aspects of our daily life. Its importance as a medium for business transactions will grow during the next years. B2B market places provide furthermore new kinds of services in the construction industry. Construction projects become ever more complex. It also exist a large number on project participants, which are at different places and have to co-operate with one another. This requires a new methodology of collaboration that particularly applies to the execution of BAB-processes. BAB-processes are to be controlled economically and supervised in time. Therefore the use of modern and intelligent collaboration platforms is necessary. These must offer a holistic and process orientated information management. A system for BAB-processes essentially consists of the ranges: cooperation, communication, and management of projects (Leukel, Schmitz, Dorloff, 2002). There are software companies which support parts of the BAB-process via internet. These distinguish BAB platforms have different goals, technologies, and usability. The media discontinuity is a substantial lack according to existing BAB-platforms. Therefore such systems could achieve only a limited spreading. Only a holistic system could lead to success. In future, the internet will become the information exchange platform and XML will become the language independent data description format for the building and construction industry. These are the substantial conditions for the intelligent control and monitoring of projects in the area of BAB. The describing of an information exchange using the neutral XML technology for the construction industry will enable tendering, planning, procurement, regulation, invoicing, and other business processes to be conducted online. (Fensel D., Ding, Y., Schulten, E., Omelayenko, B., Botquin, G., Brown, M. andFlett,F. 2001)

Ework and ebusiness in architecture, engineering and construction

814

A BAB-platform which considers the advantages mentioned before is the e-tendering platform of the German government (http://www.e-vergabe.bund.de/). This Initiative is called e-government “Bund Online 2005” and defines technical specifications to allow electronic communication between public sector bodies in Germany and private suppliers. It is core to the government’s aim of making all public sector services available online by 2005. This system uses the advantages of the internet on the one hand and on the other hand permits an entire document exchange on the basis of the language neutral data exchange format XML. 5 CONCLUSIONS AND FURTHER WORK The definition of a holistic information exchange format and system for the construction industry increases dominantly the efficiency of planning and construction tasks. The development of a Web-based system becomes possible by the linkage of already existing, isolated software units (web services). The web service technology makes the transition from a pure document-oriented to a service-oriented business possible. This innovative family of technologies opens an enormous potential for the software development of the fiiture in the construction industry. REFERENCES Kalantari, B., Díaz, J. 2001 Der Informationsaustausch im Bauwesen geht neue Wege, In: Fachzeitschrift bauinformatik JOURNAL, 1/2001 (S. 30 ff.), Werner Verlag, Düsseldorf 2001. Díaz, J. 2002 Im Vordergrund die Leistungsbeschreibung, im Hintergrund das neue Datenaustauschformat GAEB-DA 2000; In: GAEB-Forum -: Bundesamt für Bau- und Raumordnung, im Auftrag des Bundesministeriums fur Bau, Verkehr und Wohnungswesen, Bonn Bad Godesberg, 10.April 2002. http://www.gaeb.de/ Kalantari, B., Schäffler, H., Diaz, J. 2000 Datenaustausch im Bauwesen auf der Basis von XML; In: Forum Bauinformatik—Berlin 2000, VDI Fortschrittsberichte Reihe 4 Bauingenieurwesen Nr. 163 (S. 43 ff.), VDI-Verlag Düsseldorf 2000. Diaz, J. 2002 GAEB DA2000-XML-Aktuelle und zukünftige Entwicklungen; In: VDI Fortschrittsbericht Nr. 1668; Bauen mit Computern—Kooperation in IT-Netzwerken (Beilage), Tagung Bonn, 11. und 12. April 2002, VDI-Verlag Düsseldorf 2002. http://www.bmecat.org/ http://www.bmecat.org/deutsch/index.asp http://www.eclass.de/ http://www.e-vergabe.bund.de/ Leukel, J., Schmitz, V., Dorloff, F.-D., 2002, Modeling and Exchange of Product Classification Systems using XML, in: Proceedings of the 4th IEEE International Workshop on Advanced Issues of E-Commerce and Web-based Information Systems (WECWIS 2002), 26.–28.06.2002, Newport Beach, California, USA, S. 242–244. Fensel D., Ding, Y., Schulten, E., Omelayenko, B., Botquin, G., Brown, M. and Flett, F. 2001: Product Data Integration in B2B E-commerce. IEEE Intelligent Systems, 16(4):5459. http://informatik.uibk.ac.at/users/c70385/ftp/paper/ieee.ec.pdf

Mobile computing

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Mapping site processes for the introduction of mobile IT S.L.Bowden & A.Dorr Arup, London, U.K. A.Thorpe & C.J.Anumba Loughborough University, Leicestershire, U.K. ABSTRACT: Due to its nature, the construction industry requires its personnel to be mobile, to communicate efficiently and to exchange, analyse and synthesise large volumes of information. The construction industry’s drive towards utilising IT to enhance communication, both within a company and between clients, consultants, contractors, subcontractors and suppliers, has, to date, largely ignored the need to deliver information effectively to mobile personnel e.g. whilst on site or attending a client meeting. The advent of suitable devices and software solutions will go some way to correct this. However, simply because the technology is now available it should not be indiscriminately applied. This paper documents activities undertaken to better understand which construction processes would derive most benefit from the application of mobile information and communication technologies. The approach taken also illustrates how these processes linked together thus providing an optimum implementation plan for mobilising site-based processes. This research forms part of a larger study (known as COMIT).

1 INTRODUCTION Construction affects the overheads of all industrial and commercial activities, and the international competitiveness of all industries can be improved through better construction productivity and quality. In order to genuinely improve construction project performance against key criteria of time, cost, quality, safety, the environment and respect for people, the organisations in the construction supply chain need to become more integrated through increased internal and external collaboration. Collaboration requires communication and mobile, point-of-activity, digital tools clearly can make a significant contribution to improving project performance. Computer tools have already changed the ways buildings are designed, procured and constructed,

Ework and ebusiness in architecture, engineering and construction

818

but now communication and knowledge-sharing techniques at and between points of activity offer further potential for increased productivity, faster construction, higher quality, and lower cost. Currently, many people in the construction industry are prevented from efficiently and effectively contributing to the information flows that are crucial to any business. Error rates in data collection are high; the speed and immediacy of data receipt, capture and feedback require significant improvement; information exchange is expensive; and audit trails are by no means automatic. Delays, variable productivity, accidents, and quality problems are therefore commonplace (Egan, 1998). The development of affordable mobile technologies has enabled their deployment across all sectors of industry and commerce. From bar codes on the weekly shopping to hospital consultants recalling a patient’s records using a PDA, the ability to capture, store and re-use information by a mobile user is now commonplace. Although the European construction industries are the largest industrial cluster in the European Union, representing 11% of total gross domestic product (GDP) with an annual turnover of £520 billion and a quarter of all industrial output, this sector is still an immature market for mobile technology solutions providers. The recent advances in technology have increased the performance and reduced the price of many mobile computing devices, resulting in renewed interest in their potential application in the construction process. 2 THE COMIT PROJECT The COMIT project, Construction Opportunities for Mobile IT, was formed to address the issues outlined above. COMIT is a two-year research and development project ftmded by the UK’s Department of Trade and Industry led by Arup, in partnership with BSRIA and Loughborough University. A key element in the project is the formation of the COMIT community which is formed of representatives from the key stakeholders: – Construction and engineering companies – Technology providers – Research and development institutions – Dissemination companies The community, which comprises 50 different organisations, provides the research team with guidance and input to the deliverables, making sure they are providing what is needed. The primary objectives of COMIT are to: – Document existing applications of Mobile IT in Construction – Create a better understanding between technology and construction companies – Understand which applications will deliver business benefits – Create wider awareness of the benefits of Mobile IT in construction This paper focuses on the third objective: to understand which applications will deliver business benefits.

Mapping site processes for the introduction of mobile IT

819

This activity provided the COMIT community with a mechanism to decide on which processes should be implemented on real construction projects (the “demonstration projects”) in order to verify the theoretical benefits that were postulated. 3 INFORMATION NEEDS OF MOBILE PERSONNEL There have been many attempts to categorise and identify construction information. Researchers have filtered site information to a greater or lesser extent, from a high-level division into technical, commercial, management and control (BT, 1995) to a more detailed level where different types of documentation are classified, e.g. technical queries, dayworks, requisitions, and method statements (Murray & Thorpe, 1996), to classification by job-type (Tenah, 1986). Bowden (2002) conducted a survey of site-based personnel which concluded that they are both recipients and producers of paper-based information. The paper-based tasks that they carry out in their normal work are numerous (85 different tasks were identified). These were grouped into different document types revealing the most commonly identified tasks as completing data collection forms (25%), dealing with correspondence (18%), viewing and reviewing drawings (13%) and reading and writing specifications (6%). It was shown that the documentation to which sitebased personnel would like to have access in the field is related to the paper-based tasks that they carry out as part of their normal work. This provides support for Tenah (1986) who found that information needs are inextricably linked to the management responsibilities of each member of the project team. The survey results showed that the document types site-based personnel would find most useful to have access to/record in the field (out of the office) were drawings (24%), data collection forms (12%), correspondence (8%), progress information (7%) and specifications (7%). 4 MOBILE IT APPLICATIONS Since the late 1980’s, both the academic and industrial sectors have been investigating the use of Mobile IT for developing applications used in field data collection. Researchers have looked at the application of Mobile IT to the following processes: – Progressrecords(Cox et al., 2002) – Site diaries (Scott, 1990) – Resource management (McCullouch & Gunn, 1993) – Construction documentation (Williams, 2001) – Quality inspections (Cox & Issa, 1996) – Maintenance conditions (Rojas & Songer, 1997) – Snagging/Defects management (Mobbs, 2002) – Health and safety (Hawkins, 2002) – Site design problem resolution (Liu, 1995) – Monitoring piling activities (Ward et al., 2003)

Ework and ebusiness in architecture, engineering and construction

820

The benefits identified by this research can be broadly categorised as follows (Bowden & Thorpe, 2002): – Improving efficiency of data capture – Improving access to data – Reducing errors and improving data integrity However, it is clear that for any proposed system to be acceptable it has to be technically, economically and operationally feasible. For a system to be economically viable, the cost savings must be sufficient to justify the investment concerned and pay back the investment within a realistic time-span given the technology involved and the business environment concerned (Baldwin et al., 1994). 5 PROCESS MAPPING Many people have argued that construction products are one-off with each project being unique—however, the same underlying procedures and processes are adopted time and again (McConalogue, 1999). The quality, quantity and timing of information can either hinder or facilitate the successful completion of projects. It has been suggested that the cost of construction can be reduced by 25% through the efficient transfer of information (Davidson & Moshini, 1990). To fully understand these construction procedures and processes and to identify the opportunities to increase the efficiency of information transfer, a consistent approach must be utilised. “Process Mapping” is a management tool initially developed and implemented by General Electric as part of their integrated “Work-out,” “Best Practices,” and “Process Mapping” strategy to improve significantly their bottom line business performance (Hunt, 1996). There have been many research projects investigating how to map construction processes (Baldwin et al., 1999). Numerous systems are available, these include: – PetriNets – Function Decomposition – Structure Charts – HIPO Diagrams – Warnier-Orr Diagrams – Action Diagrams – Decision Trees – HOSCharts – IDEF0 – Entity Relationship Diagrams – Data Flow Diagrams Karhu (2000) provides a comparison of six commonly used methods; scheduling method, simple flow method, IDEFO, IDEFOv, IDEF3 and Petri Nets. He concludes that these process modelling methods have been developed for specific purposes. Therefore, a more general method is required that eliminates the difficulties associated with the process

Mapping site processes for the introduction of mobile IT

821

model graphical representations being too complicated for the employees involved within the process to interpret and hence make meaningful contributions. 6 METHODOLOGY To identify which construction processes would benefit most from the introduction of Mobile IT, the following four stage approach was adopted (see Figure 1): – Stage 1: Identify ten processes to look at in further detail – Stage 2: Map out the “As Is” process for each of the ten – Stage 3: Map out the “To Be” process for each of the ten – Stage 4: Select four processes to be implemented on the demonstration projects

Each of these stages is discussed in further detail below. 6.1 Stage 1: Identify ten processes The research team conducted a literature review to identify which construction processes could be suitable for the introduction of Mobile IT and which technologies would be applicable. These processes involve personnel working away from their desks and/or the transfer of information from that point-of-activity. The processes were categorised into: – Communications (e.g. design professional to foreman)

Figure 1. Research methodology. – Data capture (e.g. goods received notes) – Identification (e.g. accounting for equipment/ materials on site) The COMIT community was presented with a list of thirty processes and asked for any additional processes they might wish to include. They then discussed which processes

Ework and ebusiness in architecture, engineering and construction

822

they thought had most potential. Finally, they voted for their top ten processes. This resulted in the following ten processes being selected to be investigated further: – Goods received notes – Drawing distribution and usage – Task allocation – Monitoring progress – Monitoring health and safety on site – Quality inspections – Site design problem resolution – Site diaries – On-site accounting of operatives/visitors – Maintenance inspections 6.2 Stage 2: Map out the “As Is” processes The primary objective of the process maps that were developed was to present an illustration to the COMIT community of the possible efficiency gains Mobile IT could provide in order that the community could determine which processes should be selected for implementation on the demonstration projects. Hence, it was decided that a simple graphical representation, readily understood by construction professionals, should be used. As these maps were to be developed by several parties and it was vital that they should be in standard format to enable comparison by the COMIT community it was decided that a suitable software product should be found. This product should also provide the capability to publish the maps on the Internet so that the maps could be viewed and used by anyone without the need for the process mapping software. Following a search and review of available tools the Triaster product “Process Navigator” was selected. This is powered by Microsoft Visio, and designed for nonprocess specialists, hence it was very simple and easy to learn to use. Data was collected from the COMIT community, and other relevant external contacts. This was provided in the form of project procedures, form templates, or narrative explaining what the construction company currently does. Input was received from 25 companies, including most of the major UK contractors. This information was then collated to map out the generic “As Is” process for each of the ten. The contributors then verified the “As Is” maps to ensure that they reflected the current situation accurately. 6.3 Stage 3: Map out the “To Be” processes Once the “As Is” maps had been verified, areas for improvement were identified. These included: – Activities where information was collected on paper at the point of activity – Activities that could be fully automated if electronic data was collected at the point of activity – Activities involving the delivery of paper information

Mapping site processes for the introduction of mobile IT

823

– Activities involving the notification of personnel using traditional means (e.g. by telephone) These areas were highlighted on the “As Is” maps and Mobile IT, such as tablet PCs, hand-held computers, digital pens, barcoding, RFID tags, SMS messaging, GPRS/GSM and Wireless LAN, were proposed where their use would improve the overall process. The resulting changes in the process were then mapped out to form the “To Be” maps. For both the “As Is” and the “To Be” maps a colour coding for the deliverables was used: green—electronic file, orange printed document (structured but handwritten input), red— handwritten document. A narrative was written to accompany each set of maps. This provided an overview of the process, the issues that are present with the current approach, ideas for mobile solutions, details of the benefits that they bring and an assessment of how easy the solutions would be to implement. To ease the choice of the final four processes mobilisation “scores” were given. These provided a subjective assessment of how widely available relevant solutions are, the benefits to the end-user, the benefits to the organisation and the ease of implementation. These “scores” were given at the top of each process narrative to provide information at a glance and help the COMIT community to decide which processes should be considered for the implementation of Mobile IT pn the demonstration projects. The scores were assessed as follows and then subsequently verified by the COMIT community in Stage 4. An assessment of available solutions is made in accordance with how many solutions are available, their affordability, and are they in current use in the construction industry and/or will they require customisation to suit the particular process under consideration. The scores given were; Many, Several, and Few. For any mobile solution to succeed it must deliver benefits that are directly apparent and of value to the end-user. This will encourage the adoption of the solution and hence help to deliver the organisational benefits. The scores given were; High, Medium, and Low. User benefits will result in benefits to the organisation. In addition benefits will be derived through the collection of more accurate information, the reduction of information transfer time and the ability to search and utilise the electronic information subsequently. The scores given were; High, Medium, and Low. The ease of implementation is assessed in accordance with whether the solutions are already in use on construction or similar industries, the readiness of the users to take up the technology and the current extent of electronic information in the process. Hence a judgement can be made on the length of time and the effort that would be involved in the implementation. The scores given were; Easy, Medium and Hard. 6.4 Stage 4: Select four processes The COMIT community was presented with the “As Is” and “To Be” maps and the associated narratives. Once all of the processes had been reviewed, the construction companies were asked to vote for the top four processes they wished to see implemented on the demonstration projects. The four selected were:

Ework and ebusiness in architecture, engineering and construction

824

– Monitoring health and safety on site – Monitoring progress – Site design problem resolution – Maintenance inspections The “As Is” map for each of the four processes will be developed to be project specific for the demonstration project and the proposed times and activity owners will be verified. Then once the demonstration projects have commenced the “To Be” maps will be verified and quantitative data will be collected to illustrate the process changes. 7 MONITORING CONSTRUCTION PROGRESS Monitoring construction progress is detailed here to provide an example of the mapping activities carried out. By enhancing information flow between the different site processes and teams, it is easier to monitor, control and assess the project progress and hence integrate the on-site process (Moniem, 2000). Site issues need to be resolved quickly and efficiently to avoid cost overruns and this often requires collaboration between on and off-site personnel (Miah et al., 1998). However, most project information is currently stored on paper, which is difficult to access and requires large storage space. A computerised information system can store vast amounts of data efficiently, and information can be located and viewed quickly through computerised searching and display (Liu, 1995). Scott (1990) defined progress records as including personal diaries, minutes of progress meetings, daywork sheets, photographs and weekly progress reports. The main applications of these are: — To confirm that work has been carried out — To assess the progress of works — To provide the main source of information detailing exactly what occurred Initially, a project programme is drafted which provides a forecast of ftiture works on a project. This is used to produce weekly progress sheets detailing the week’s activities, the expected progress and a column to be completed for the actual progress. Site engineers report back on a percentage complete (normally weekly) using visual inspection/numerical methods. The progress sheets are then compared with expected progress and the project programme is updated accordingly (see Figure 2). Monitoring progress is vital to ensuring work is completed on time and that the project is progressing as planned. Penalties for the failure to complete on time will usually result in having to pay liquidated and ascertained damages (LADs), which could eliminate any potential profit that the contractor expected to make from the entire project. Currently this process is heavily paper-based, and relies on the site engineers returning their progress sheets at the designated time. The information required is collected in many different locations on site and provided by several site engineers.

Mapping site processes for the introduction of mobile IT

825

Figure 2. Monitoring progress—“As Is” map. It is important that progress information is circulated to the entire project team including architect and consultants, as they may be able to provide ideas for getting the project back on track. The following issues were raised for this process: – The process of reporting on progress is highly repetitive and laborious; therefore the quality of the information collected will suffer – Progress reports often rely on the subjective assessment of percentage complete by the site engineer rather than an objective analysis – The collation of data from several different sources is time-consuming and prone to data entry mistakes – Formal reporting on progress only occurs periodically; therefore potential problems are often not foreseen before they occur – Data transfer is often carried out manually between the progress reports which are produced in Microsoft Excel and the project programme produced using planning software The following Mobile IT solutions were proposed for the monitoring progress process and a two stage approach was recommended. The first stage will simply provide a form on a PDA electronic data capture at the point-of-activity. The second stage will integrate this further into the back-end systems. A form could be created for use on the PDA to enable the site engineer to capture progress made whilst he is out on site. This could be distributed over the network such that each time the site engineer collects his/her PDA it is pre-loaded with the week’s progress form. Once the form is completed it could either be synchronised when the site engineer gets back to the site office or it could be synchronised via WLAN or GPRS whilst out in the field. Due to the nature of the data collected it is not thought necessary to provide progress data on more than a daily basis, hence synchronisation on return to the site office would be sufFicient. The data can then be fed into a progress database which would collate the data from each site engineer. This would enable the project progress report to be generated automatically.

Ework and ebusiness in architecture, engineering and construction

826

The difficulty with producing the form for the PDA would be that the content of the form would change on a weekly basis according to the project programme. Greater benefits would be gained from enabling the forms to be automatically generated from the project programme. The data collected could then be fed straight back in to update the project programme. Alternatively, relevant programme information could be distributed such that the site engineer can see each programme activity and simply select the completed tasks e.g. they could tick completed “drainage

Table 1. Areas for improvement. “As Is”

“To Be”

Planner copies and distributes blank progress System distributes any revised/new blank progress sheets to site engineers sheets 30 minutes each week

0 minutes each week

Site engineer returns completed progress sheets to the planner

Completed progress sheets are synchronised with the central progress database

30 minutes each week

3 minutes each week

Slippages are alerted to all of the project team

Slippages are alerted automatically via SMS

1 hour each month

0 minutes each month

Planner produces (monthly) progress report

System automatically generates (monthly) progress report

3 hours each month

0 hours each month

run from A to B” and automatically the materials usage is calculated. Linear activities could use GPS to show the distance completed but this may need to be supplemented by GPRS and Inertial Navigation data to obtain a desired accuracy of position. Potential areas for improvement to the generic “As Is” process were identified (see Table 1 and Figure 3). The times given above are indicative only and will be verified on the demonstration projects. Using these times an overall time saving of at least 1 day each month of the planner’s time is achieved by using Mobile IT. However, there are other benefits that are more difficult to map and measure. Capturing progress information directly in the field provides contemporaneous information, eliminating errors typing up information from handwritten notes or from memory. It also allows the site engineer to spend more time out on site undertaking work that enables the project to be completed on time and on budget. Providing an easy way for site engineers to capture the information may lead to the information being collected on a more regular basis. This increased feedback could help in the early identification and troubleshooting of many problems, thus avoiding unnecessary escalation of issues on site. Slippage alerts could be generated automatically and emailed to the appropriate person who can initiate remedial measures.

Mapping site processes for the introduction of mobile IT

827

The correlation of the progress information is automated, monthly progress reports can be generated at the touch of a button, and the information can be manipulated and displayed easily. Many potential error-prone manual paper processes are skipped, saving worker time and resources. The project team will have access to more timely and accurate programme information and will be able

Figure 3. Monitoring progress “To Be” map. to move from trying to understand what has happened to figuring out what to do about it. An assessment was also made for the ease of implementation of a Mobile IT system for this process. The provision of a PDA form for the collection of progress information is relatively simple and there are many packages available that can be used to create the form. Initially this form could have the same appearance as the current paper forms thus providing the user with a familiar interface. Primavera, a major provider of project management software offer a solution called Mobile Manager, which provides programme information through a PDA. Although this alleviates the issue of linking progress information back into the project programme it provides a more complex interface which may be less readily understood and hence used. It also relies on Primavera being used for creating the project programme, which may not always be the case. The mobilisation “scores” given for this process were: – Available solutions: Several – User benefits: Medium – Organisational benefits: High – Ease of implementation: Medium The COMIT community ranked this process joint first alongside monitoring health and safety on site.

Ework and ebusiness in architecture, engineering and construction

828

8 MOBILISATION PLAN The mapping approach that was followed enabled the identification of common deliverables and personnel across the ten processes e.g. the Project Plan is

Figure 4. Process linkages. utilised in the processes for Monitoring progress, Task allocation, Goods received notes, Quality inspections and site diaries. This provides a guide to which processes should be “mobilised” in which order, although the benefits achievable should also be taken into account. Figure 4 illustrates how closely related the information requirements of each process are. It is suggested that justifying the business case for one process can be enhanced by choosing a process that utilises information common to other processes. Once the first process has been “mobilised” some of the electronic data required to mobilise a subsequent process is already provided. Additionally, the equipment required is already available, the users may be the same and hence the barrier to acceptance of a new solution is lowered and also the training required. 9 NEXT STEPS Mobile IT solutions are currently being developed for the four processes that have been selected for implementation on the demonstration projects. Training and implementation will begin in Autumn 2004 and the projects will be monitored until July 2005.

Mapping site processes for the introduction of mobile IT

829

Quantitative data will be collected to verify the costs to the contractor and the benefits that Mobile IT brings. This data will be collated and compared across the four projects to demonstrate real-life business cases for Mobile IT. In addition, human factors and cultural barriers will be analysed and reported on to provide the construction industry with comprehensive guidance in order to aid future development and implementation of appropriate Mobile IT solutions. 10 CONCLUSIONS Mapping the “As Is” processes provided the research team with a sound basis on which to determine the “To Be” processes. Mapping each activity and deliverable and highlighting the areas for improvement enabled ideas for the “To Be” process to be developed, often resulting in unforeseen improvements. The knock-on effects of implementing a Mobile IT solution were also much more clearly identifiable. One of the difficulties with illustrating the changes through the process maps was that the “To Be” map often appeared more complicated than the original “As Is” map. This was due to the use of a central database which created feedback loops on the maps, and automated activities still being included on the maps. It would be useful to illustrate the changes in activities for each individual participant so they can see graphically a real reduction in activities and the time taken to complete them. Although the maps provide an indication of the improvements that could be made there is no real substitute for the information that can be gathered from a pilot project and the demonstration projects will enable us to improve on the process maps by providing a real view of the “To Be” process and the associated quantitative information. REFERENCES Baldwin, A.N., Austin, S.A., Hussan, T.M., & Thorpe, A. 1999. Modelling Information Flow During Conceptual and Schematic Stages of Building Design. Construction Management and Economics 17:155–167. Baldwin, A.N., Thorpe, A., & Alkaabi, J.A. 1994. Improved Materials Management through BarCoding: Results and Implications of a Feasibility Study. Proceedings of the Institution of Civil Engineers, Civil Engineering 102(4): 156–162. Bowden, S. 2002. The Appropriate Use of I.T. on a Construo tion Site, MSc, Loughborough University. Bowden, S., & Thorpe, A. 2002. Mobile communications for on-site collaboration. Proceedings of the Institution of Civil Engineers, Civil Engineering 150(Nov. 2002): 38–44. BT 1995. Construct I.T.—Bridging the gap—An information technology strategy for the UK construction industry Construction Sponsorship Directorate, Department of the Environment, UK. Cox, R.F., & Issa, R.R.A. 1996. Mobile field data aquisition for construction quality control and ISO 9000 certification, in Computing in Civil Engineering. Cox, S., Perdomo, J., & Thabet, W. 2002. Construction Field Data Inspection Using Pocket PC Technology, in International Council for Research and Innovation in Building and Construction, CIB w78 conference 2002, Distributing knowledge in building. Aarhus School of Architecture, 243–251.

Ework and ebusiness in architecture, engineering and construction

830

Davidson, C.H., & Moshini, R. 1990. Effects of organisational variables upon organisations’ performance in the building industry, in CIB-90 Building Economics and Construction Management. J.Ireland & T.Uher, eds., Egan, J. 1998. Rethinking Construction (The Egan Report), London: DETR. Hawkins, G.A. 2002. The use of Psion Teklogix handheld computers by Laing Utilities for conducting safety audits. Hunt, D.V. 1996. Process mapping: how to reengineer your business processes. Chichester: Wiley. Karhu, V. 2000. Proposed new method for construction process modelling. International Journal of Computer Integrated Design and Construction 2(3): 166–182. Liu, L.Y. 1995. Digital Data-Collection Device for Construction Site Documentation. Computing in Civil Engineering 2: 1287–1293. McConalogue, N.H. 1999. Knowledge Management in the Construction Industry, A study of Major UK Contractors, MSc, Loughborough University, UK. McCullouch, B.G., & Gunn, P. 1993. Construction field data aquisition with pen based computers. Construction Engineering and Management 119(2): 374–384. Miah, T., Carter, C., Thorpe, A., Baldwin, A.N., & Ashby, S. 1998. Wearable computers—an application of BT’s mobile video system for the construction industry. BT Technology Journal 16(1): 191–199. Mobbs, J. 2002. Construction company goes for zero defects with symbol 1700-based fault snagging system. Murray, J.J., & Thorpe, A. 1996. COMPOSITE Site Communications Survey. Rojas, E.M., & Songer, A.D. 1997. FIRS: A vision of the future of building inspection, in Proceedings of the Fourth Congress in Computing in Civil Engineering. ASCE, 25–32. Scott, S. 1990. Keeping better site records. Project Management 8(4). Tenah, K.A. 1986. Information needs of construction personnel. Construction Engineering and Management 112. Ward, M., Thorpe, A., Price, A., & Wren, C. 2003. SHERPA: Mobile wireless data capture for piling works. Journal of Computer Aided Civil and Infrastructure Engineering 18(4): 200–220. Williams, T.P. 2001. Providing construction documentation using hand-held computers.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Mobile field data entry for concrete quality control information I.L.Kondratova National Research Council of Canada, Institute for Information Technology e-Business, Canada ABSTRACT: This paper discusses the advantages and challenges of using multimodal and voice technologies for field data collection on the construction site. Current developments in the multimodal, mobile, field data communications are discussed. Multimodal and VoiceXML technology for speech-enabled information retrieval and input using speech over the phone is explained. This paper describes an innovative solution for field entry of quality control data and real-time communication that utilizes concepts of voice and multimodal interaction for field data entry on a handheld device. In this project, a field concrete testing technician can enter test results using variable interaction modes such as speech, stylus and keyboard via a handheld device, or speech-only on a mobile phone. The multimodal prototype application, for data collection in the field, includes a fat wireless client on a Pocket PC that has a multimodal browser, embedded speech recognition technology, and is based on X+V technology. The speech-only prototype, for field data collection, is based on VoiceXML technology that allows data retrieval and input using natural speech on the mobile phone.

1 INTRODUCTION Multimodal interaction can be described as the integration of visual and voice interfaces through the delivery of combined graphics and speech, on hand-held devices (Hjelm, 2000). This technology enables more complete information communication and supports effective decision-making. It also helps to overcome the limitations imposed by the small screen of mobile devices. A small screen size, and the need to use a pen to enter data and commands, presents a great inconvenience for field users—especially if their hands are busy using other equipment, or instruments. Speech processing is one of the key technologies to simplifying and expanding the use of handheld devices by mobile workers (Burkhahardt et al, 2002; IDC Viewpoint 2002). 2 MULTIMODAL INTERACTION TECHNOLOGY There are different models for implementing multimodal interaction on mobile devices. The fat client model employs embedded speech recognition on the mobile device and

Ework and ebusiness in architecture, engineering and construction

832

allows conducting speech processing locally. The thin client model involves speech processing on a portal server and is suitable for mobile phones. Currently there are two markup languages proposed for creating applications that use voice input (speech recognition) and output (speech synthesis) and support multimodal interaction. Speech Application Language Tags language (SALT) is a lightweight set of extensions to existing markup languages, in particular to HTML and XHTML (XHTML is essentially HTML 4.0 adjusted to comply with the rules of XML), that enables multimodal and telephony access to information, applications and Web services from PCs, telephones, tablet PCs and handheld devices. SALT applications can be implemented using the thin client model with speech processing done on the speech server (Moraes, 2002). Another markup language that is currently proposed for developing multimodal Web applications is VoiceXML+XHTML (X+V) (W3C Multimodal Activity, 2004). It combines XHTML and a subset of VoiceXML (Voice Extensible Markup Language). Currently VoiceXML is the major W3C standards effort for voice-based services (W3C Voice Browser Activity, 2004). VoiceXML provides an easy, standardized format for building speech-based applications. Together, XHTML and VoiceXML (X+V) enable Web developers to add voice input and output to traditional, graphically based Web pages. This allows the development of multimodal applications for mobile devices based on the fat client model that includes a multimodal browser and embedded speech recognition on a mobile device, and a Web application server (Figure 1).

Mobile field data entry for concrete quality control information

833

Figure 1. X+V architecture for multiple devices. While both X+V and SALT use W3C standards for grammar and speech synthesis, only X+V is based entirely on standardized languages. X+V’s modular architecture makes it very simple to separate an X+V application into different components. As a result, X+V applications can be developed in parts, with experts in voice programming developing voice elements and experts in visual programming developing visual ones. X+V’s modularity also makes it adaptable to stand-alone voice application development. Another feature of X+V is that it leverages open industry APIs like the W3C DOM to create interoperable web content that can be deployed across a variety of end-user devices (VoiceXML Forum, 2004). At the same time, SALT’s reliance on the containing environment makes it very difficult to disconnect its coding functions, and makes the language insufficient for the task of stand-alone application development. As a result, the application developer must

Ework and ebusiness in architecture, engineering and construction

834

generate different versions of the application for each execution environment (for example, mobile phones or PDAs from different manufacturers). X+V technology for multimodal interaction with mobile devices is based on VoiceXML technology for voice access to Web services. VoiceXML technology and examples of VoiceXML field services prototypes are described in the following section of the paper. 3 VOICEXML TECHNOLOGY VoiceXML technology follows the same model as the HTML and Web browser technologies. Similar to HTML, a VoiceXML application does not contain any platform specific knowledge for processing the content; it also does not have platform specific processing capability. This ability is provided through the Voice XML Gateway that incorporates Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) engines (Kondratova, 2003). VoiceXML allows providers to deliver Web services using voice user interfaces (VUIs). Developers can use VoiceXML to create audio dialogues that feature synthesized speech, digitized audio, recognition of spoken and touchtone key input (DMTF), recording of spoken input, telephony, and mixed-initiative conversations (Beasly et at, 2002). The words or phrases that a VoiceXML application must recognize are included in a grammar. Large grammars can cause application problems because they can result in recognition errors. Small grammars can cause VUI problems because they require prescriptive prompts that limit the use of natural language dialog. However, small grammars could be used successfully in designing applications for industrial users that are trained in using the application (Kondratova, 2003). The advantage of using the VoiceXML language to build voice-enabled services is that companies can build automated voice services using the same technology they use to create visual Web sites, significantly reducing the cost of construction of corporate voice portals. A voice portal provides telephone users, including mobile phone users, with a speech interface to access and retrieve Web content. In the next section of the paper, to demonstrate the capabilities and mobile applications of voice technology, the author describes several prototype systems developed for the mobile workforce. 3.1 VoiceXML for field applications The full potential of speech-based information retrieval for industrial purposes is not yet harnessed and there are only a handful of existing field applications of VoiceXML technology. For example, Florida USA Power and Light Co. is using a VoiceXML based system for field restoration crews. Using mobile phones, restoration crews can find out about storm-damaged equipment, and report back to the system on the status ofthejob. Considering the widespread use of the mobile phone in industrial field applications, there is an opportunity to apply VoiceXML technology for field applications in construction, manufacturing, power and resource industries. These industries can benefit from voice-enabling their operations. The ongoing NRC research program on Voice and

Mobile field data entry for concrete quality control information

835

Multimodal communications specifically targets industrial field applications of Voice Web technologies. 3.2 Voice inventory and time management prototypes The Voice Inventory Management System (VIMS) prototype, developed at NRCIIT eBusiness, allows a mobile worker to easily retrieve product and warehouse information out of the Web-based warehouse database, in real-time, using a regular, mobile phone, or phone-enabled handheld device and natural speech dialog. The VIMS application keeps track of a series of products and warehouses in a database. All products in the database are entered into the VIMS speech recognition grammar, so that the grammar is updated dynamically with the information on current products in the database. Each product and warehouse has a number of attributes. Each product has a price, product number and description and is associated with the warehouses that product is located in. Each warehouse has an address, and information on the contents of that warehouse. The system also keeps track of product types, represented by a tree that links particular types of products together (Kondratova, 2003). The Voice Time Management System (VTMS) prototype was developed to allow field crewmembers to enter their time in the time management application, on the corporate server, using a mobile phone. This technology, if implemented, could potentially allow timely billing of the client for the field services provided and bring substantial savings to service providers. The system was designed to fill information as required by the standard timesheet for a construction project. VTMS is designed to keep track of the user’s hours for each job, work number and day and store this information in the corporate database. Using voice commands with VTMS, a field service worker can retrieve and input information from a timesheet that is unique to the caller. A user can retrieve information such as hours worked on a particular day for a unique work number. A user can also find out the total hours worked for the week and the total hours worked on a particular work number for a job and update time information such as hours worked on a particular day (Kondratova, in press). Both prototype systems have undergone in-house performance and usability testing in an industrial noise environment (about 60–70 dB) and were found to be performing quite well in terms of accuracy of speech recognition and ease of navigation (Kondratova, 2004). However, both prototypes are limited to voice only input and output for data entry and access. To provide users with multimodal interaction capabilities for data entry and retrieval, a multimodal field data collection application on the Pocket PC was developed using X+V technology. 4 MULTIMODAL FIELD DATA COLLECTION To facilitate speedy field data collection and timely decision-making, especially in the case of field quality control inspection it would be highly beneficial to use multimodal wireless handheld devices capable of delivering, voice, text, graphics and even video. For example, “hands free” voice input can be used by a concrete technician in the field to enter inspection information using a hybrid phone-enabled PDA and a wireless,

Ework and ebusiness in architecture, engineering and construction

836

Bluetooth technology enabled headset piece. This information could be entered directly into the inspection forms on the handheld device and stored locally in the embedded database or wirelessly transmitted to the backend database server. Thus, field inspection information could be communicated in real time to facilitate timely decision-making on the construction site and at the ready-mix plant. This information will be stored in the project database and retrieved easily, if needed, in case of litigation. By combining a multimodal mobile handheld device with a GPS receiver and a Pocket GIS system, the gathered inspection information could be automatically linked to its exact geographical location. In addition, other environmental sensors, such as temperature and moisture sensors could also be connected to a handheld device, if needed (Giroux et al, 2002). 4.1 Wireless field quality control data entry Our current project on wireless, field quality control data collection is based on concepts of both multimodal and voice field data collection. In this project, a field concrete testing technician will be able to enter field quality control information into the Concrete Quality Control Database using various interaction modes such as speech, stylus and keyboard on the handheld device or speech on the mobile phone. The multimodal field data entry application (MFDE) includes a fat wireless client on a Pocket PC that has a multimodal browser and embedded speech recognition, and is based on X+V technology, described previously in this paper. The voice-only data collection application is based on the VoiceXML technology that allows data retrieval and input using natural speech on the mobile phone, similar to the VIMS and VTMS applications described in the previous section. The high-level system architecture for the prototype MFDE application is similar to the one shown in Figure 1. This proof of concept prototype was developed for the wireless Pocket PC utilizing multimodal NetFront 3.1 browser and a fat client with embedded

Mobile field data entry for concrete quality control information

837

Figure 2. Multimodal field data collection usage scenario. IBM Via Voice Speech recognition engine (IBM Pervasive computing, 2004). An embedded relational database (IBM DB2 everyplace) was used for local data storage on mobile device. 4.2 System design and functionality The two usage scenarios for the field concrete quality control multimodal application are presented in Figure 2. A quality control inspector on a construction site will be using a wireless handheld device to collect field inspection data. Since the application is multimodal, an inspector can fill in the report form by using voice or stylus. On a site with wireless coverage an inspector has the option to update the information in the concrete quality control database directly through the synchronization server. Thus, inspection information is communicated in real time and necessary adjustments to the concrete shipped to the site could be made, if needed. If there is no wireless coverage on site, an inspector will be using a stand-alone multimodal application on the handheld device. This application utilizes an embedded database to store data and access past records stored on the handheld device. Back at the office information stored in the embedded database will be synchronized with the backend concrete quality control database through the synchronization cradle, desktop computer and the synchronization server. Field information could also be entered into the backend database through a mobile phone utilizing VoiceXML technology as it is done for the Voice Time Management system described earlier. 4.3 User interface design The work on the development of the proof-of concept MFDE application for concrete quality control data collection is conducted in collaboration with the New Brunswick Department of Transportation (NBDOT) concrete quality control engineers and the University of New Brunswick. A graduate student in Civil Engineering, in consultation with NBDOT staff, developed field data entry forms for concrete quality control information. These forms were placed in the Web-based construction project management system. We adapted the design of the field quality control forms for multimodal data entry on the Pocket PC. A screen shot of the Main Menu for the concrete quality control multimodal field data entry application (MFDE) is given in Figure 3. This menu provides options to search, delete and edit old reports, as well as, an option to create and save new reports using voice and stylus or keyboard.

Ework and ebusiness in architecture, engineering and construction

838

Figure 3. Main Menu for MFDE (interaction with voice, stylus or keyboard). A Concrete Placing Report form is shown in Figure 4. It contains drop down menus, as well as entry fields for information such as a sample ID or contract number that could be filled in by using a stylus or by entering information by voice. A Grammar Menu shown in Figure 5 allows minor editing of the MFDE's VoiceXML grammar, including entering names of new contractors or adding material options. The quality control technician could do this on-site to keep the information in the database

Mobile field data entry for concrete quality control information

839

current. The grammar for the application is dynamically updated by updating information in the database.

Figure 4. Concrete Placing Report form (interaction with voice and stylus or keyboard).

Ework and ebusiness in architecture, engineering and construction

840

Figure 5. Grammar Menu (interaction with stylus or keyboard). Thus, major grammar adjustments will be made using a desktop version of the application and later synchronized with the grammar on the handheld device. 5 TECHNOLOGY CHALLENGES In the multimodal prototype development phase we experienced some challenges associated with the novelty of the multimodal technology, including unresolved interoperability issues, mobile OS limitations and also challenges associated with a

Mobile field data entry for concrete quality control information

841

limited number of multimodal browser vendors. We hope that the mobile industry will resolve these issues in the near future. However, one challenge will remain and will require extensive research and testing: the usability of this technology in the field. The usability evaluation for the multimodal field data entry prototype will be conducted during the next phase of our research project. 6 CONCLUSIONS The advantages afforded by the field use of multimodal and VoiceXML technology to retrieve corporate and project information and enter field data could be substantial. The availability of real-time, complete information exchange with the project information repository is critical for decision-making in the field of construction site inspection, as information frequently has to be transmitted to and received from the project repository right on-site. In some cases, when the security and safety of people and infrastructure are at stake, the importance of real-time communication of field data becomes paramount, as, for example, in assessing the damage to buildings in emergency situation (Bacheldor, 2002). In such cases multimodal applications for data collection could be used to collect other types of information such as digital pictures or video of the site. In this paper the author described applications of VoiceXML and multimodal technology for field data collection on the construction site. The multimodal field data entry prototype allows concrete technician in the field to enter testing data using speech and stylus via the handheld device, as appropriate. On a site with wireless connectivity the testing results are transmitted in real time and entered into the concrete quality control database, enhancing decision-making on the construction project. In spite of the current multimodal technology limitations, mentioned previously in this paper, this technology has great potential to overcome user interface weaknesses for mobile devices, in the field, and speed up the data collection and communication process. However, the usability issues for this novel interaction technology require special attention as user acceptance of this technology in the field will be, to a large extent, determined by its ease of use. ACKNOWLEDGEMENTS The author would like to acknowledge the support provided for the project by the National Research Council Canada and by New Brunswick Innovation Foundation, and the hard work and dedication of the University of New Brunswick Computer Science students that participated in the development of the multimodal prototype. REFERENCES Bacheldor, B. 2002. Handheld system assesses damage to see how buildings survived, Information Week, March 18, 2002.

Ework and ebusiness in architecture, engineering and construction

842

Beasly, R., Farley, M., O’Reilly, J. & Squire, L. 2002. Voice Application Development with VoiceXML. New York: SAM Publishing. Burkhahardt, J., Henn, H., Hepper, S. & Rintdorff, K. 2002. Pervasive Computing. Boston, NJ: Addison-Wesley. Hjelm, J. 2000. Research Applications in the Mobile Environment, in Wireless Information Services, John Wiley & Sons, 2000. Giroux, S., Moulin, C., Sanna, R. & Pintus, A. 2002. Mobile Lessons: Lessons based on georeferenced information, Proceedings of E-Learn 2002:331–338. IBM Pervasive Computing. 2004. Online. http://www-306.ibm.com/software/pervasive/ IDC Viewpoint. 2002. Five Segments Will Lead Software Out of the Complexity Crisis, by A.C.Picardi, December 2002, Doc#VWP000148. Kondratova, I. 2003. Voice and Multimodal Access to AEC Project Information, Mobile Computing in Architectural, Engineering and Construction, 10th ISPE International Conference On Concurrent Engineering, J.Cha et al. (eds), Swets & Zeitlinger, Lisse, Portugal: 755–760. Kondratova, I. 2004. Speech-enabled mobile field applications. Proc. of the International IASTED conference on Internet and Multimedia Systems and Applications, IMSA 2004, Kauai, Hawaii, August 16–18, 2004 (in press). Meissner, A., Mathes, L., Baxavanaki, L., Dore, G. & Branki, C. The COSMOS integrated IT solution at railway and motorway construction sites—a case study, Proc. of the Conference on eWork and eBusiness inAEC (Turkand Scherer, editors), Swets & Zietilinger, Lisse: 623–626. Moraes. 2002. VoiceXML, CCXML, SALT. Architectural tools for enabling speech applications, XML Journal, Sept. 2002: 30–25. W3C. Multimodal Activity, X+V, http://www.w3.org/TR/xhtml+voice/ W3C. Voice Browser Activity—Voice enabling the Web! http:www.w3org/Voice VoiceXMLForum. XHTML+Voice Profile 1.2. http://www.voicexml.org/specs/multimodal/x+v/12/

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Issues of context sensitivity in mobile computing: restrictions and challenges in the construction sector Karsten Menzel, Karin Eisenblätter & Martin Keller Dresden University of Technology, Germany ABSTRACT: The innovations presented in this paper rely on the Concept of the Mobile Worker (CoMoWo) as well as of Mobile, Ambient Intelligent, Networked Environment (MAIN-E). CoMoWo is based on the paradigm of Virtual Organisations. The CoMoWo pattern library and the related three-layer pattern-management framework support easy and efficient set-up, management, and dissolution of Virtual Organisations in the A/E/C-domain. In this way CoMoWo contributes to the development of innovative methods and adaptive project management models. MAINE consists of a set of technology components supporting CoMoWo, such as a multi-dimensional information framework, intelligent agents, and location based services. This will lead to supportive IT-infrastructure— mobile and fixed—providing information on demand and in the right context to the mobile worker and thus enabling novel ways of working. Domain and task specific mobile applications can be developed within that framework supporting a holistic management of built artefacts by reducing the sectorial as well as the organisational separation between the different actors.

1 INTRODUCTION Extensive coordination, communication and data exchange processes are performed during the planning, construction, and operation phases of built artefacts among the different actors involved in one specific project. So far, advantages of using information systems have been limited to office work and single tasks. Field personnel (e.g. construction managers, foremen, facility managers, or inspectors) are not able to connect to information management systems for the time being away from the office. Recently, new technologies such as mobile devices and wireless networks became available and support nearly unlimited accessibility to digital information. However, the efficient usage of these new technologies requires deep understanding of relevant activities and their inter-relationships. Current management and business process models need to be analysed and re-engineered to fully exploit the potentials of mobile technologies. Furthermore, mobile technologies need to be complemented by flexible, sophisticated information management systems. The user, working on construction sites should not be

Ework and ebusiness in architecture, engineering and construction

844

overloaded by irrelevant information and not be hampered by inappropriate services and cumbersome in- and output techniques. Last but not least different qualification profiles of potential end-users need to be taken into consideration when developing new user interfaces. Therefore, this paper starts with an analysis of typical working scenario in Architecture, Engineering, Construction, and Facilities Management Domain (A/ E/C & FM) defining so-called ‘context aspects’ contributing to an improved understanding of relevant, ‘on-site’ business processes. Based on that analysis a methodology for flexible process modelling is developed, introducing a three layer concept. This methodology is extended with pattern definitions describing an implantation strategy for mobile computer solutions. The combination of the three layer concept and the pattern definitions characterises the ‘Concept of the Mobile Worker (CoMoWo).’ The second part of this paper illustrates how Data Warehouse technology supports the generation of different dimensions representing parts of a ‘holistic information space.’ It explains how the definition of the dimension hierarchies corresponds to the context aspects specified in CoMoWo. The proposed ‘Data Warehouse Extended Platform’ (DWEP) supports the required integrated information management approach equally considering on-site construction activities as well as ‘in-house’ management and supervision processes. Furthermore, it is explained how agent technology might assist the user of mobile devices in the field supporting her/his individual requirements in specific working scenario. The combination of the DWEP with agent technology creates locationbased services, forming the ‘Mobile, Ambient Intelligent, Networked Environment’ (MAIN-E). 2 ASPECTS OF CONTEXT SENSITIVITY IN THE A/E/C-DOMAIN There are many working scenarios in the AEC & FM sector for which the usage of mobile computer systems might be beneficial. However, the efficiency of using mobile computing systems strongly depends on the specific working scenario in which they will be applied. Therefore, each system or part of the system has to be developed carefully, taking the specific requirements into account. Therefore, it is necessary to formalize, specify, and categorize aspects of context sensitive information management in the AEC & FM sector. Relevant aspects characterizing a specific situation while working in the field have been defined by Menzel et al. (2002) or Bürgy (2002). Bürgy for example developed in his work a so called ‘Interaction Constraints Mode’. However, according to the authors’ opinion this model focuses very detailed on the analysis of single tasks. Therefore, the model does only partially reflect the needs for business-process driven analysis and development of mobile applications. Furthermore, Bürgy’s definition of a work situation only considers locations and activities, whereas the activity analysis is mainly focused on the IT-aspects and considers only partially the domain specific needs such as the time aspect reflecting the evolutionary dimension of information management. Based on our analysis as well as the analysis of other research work the following definition for the term working scenario was developed:

Issues of context sensitivity in mobile computing

845

Definition: Within one specific WORK SCENARIO some ACTOR is using a specific IT-INFRASTRUCTURE to obtain, enter, view or modify INFORMATION that he/she requires to successfully accomplish his/her ACTIVITY at a specific LOCATION and TIME under specific ENVIRONMENTAL CONDITIONS. Within the next paragraphs the individual aspects characterizing a specific working scenario are explained in more detail. 2.1 The actor aspect The term ACTOR describes a unit that is responsible to perform a specific activity or a set of activities specified by a certain role; whereas a ROLE defines the required skills or the qualification profile. An actor can either be an organisational unit or an individual employee. This short definition addresses two facets of the actor aspect. Firstly, the introduction of mobile technologies on the construction site requires the involvement of a broader scope of users. Not only engineering and management personnel should be able to use mobile computers but also less qualified field workers. Therefore, systems need to adapt to the individual qualification profiles. Secondly, the integration of sub-contractors into complex, project-based IT-systems requires efficient mechanisms for the management of their additional IT-infrastructure by addressing the individual needs of small and medium-sized companies (SME). 2.2 The activity aspect The ACTIVITY aspect describes and classifies single actions, or whole packages of actions, their sequence and interdependencies among them. Activities can be hierarchically ordered and grouped. Activity specifications might be derived from already existing workflow management systems. 2.3 The IT-Infrastructure aspect The IT-INFRASTRUCTURE aspect describes and classifies the quality of the mobile, end-user device as well as the performance of its network connection. Discussions and surveys have proven that users in the field wish to access ITapplications by using mobile devices. Due to the much smaller screen size and different in- and output interfaces of the mobile devices the applications should be able to ‘adapt’ to the specific hardware configuration. 2.4 The location aspect A LOCATION is identified using a unique global position to the user. Based on these coordinates secondary, project specific descriptions of the location can be calculated as result of a reasoning algorithm. Typically, an organisation is involved in several projects. Therefore, field workers often work on different sites. Automatic positioning services allow to conclude on which

Ework and ebusiness in architecture, engineering and construction

846

site and, therefore, on which project the actor is working. Location based services will only deliver relevant information to the user. 2.5 The environment aspect The ENVIRONMENTAL aspect describes and classifies the conditions under which a mobile device is used. It includes both, the description, classification and evaluation of natural environmental aspects as well as of technological environmental aspects resulting from the type of the technical artefact to be constructed, monitored, or maintained. The environmental restrictions are very often decisive when choosing the mobile computing system, especially the device to be used. 3 THE CONCEPT OF THE MOBILE WORKER CoMoWo is based on the paradigm of Virtual Organisations. Within CoMoWo a Process Pattern Library (PPL) and a related three-layer pattern-management framework are currently developed. Both parts will support easy and efficient set-up, management, and dissolution of Virtual Organisations in the A/E/C-domain. A Virtual Organisation (VO) is an identifiable group of actors that makes substantially more use of information and communication technologies than physical presence to interact, conduct business and operate together, in order to achieve common, projectcentred business objectives. The aim of the VO is to gather complementing competencies of different actors in order to enhance efficiency and productivity while decreasing overheads. [see also: Camarinha-Mathos] Within the A/E/C & FM-domain star like organisational structures are often used to manage construction projects (see Fig. 1). The project manager and the project-centred information system are placed in the centre of this structure. Participants of the project team can join and leave such a VO in different phases of the life cycle. However, each of these organisations has its own information system which must be able to exchange information of different granularity with the project information system. Different granularity of information is required because besides the project manager two more classes of actors can be identified: the domain manager and the f ield worker. 3.1 The three-layer-approach The layer concept supports the easy decomposition of complex AEC & FM problems into different levels of granularity—so called layers of information management. Each of these layers should have its own paradigms for modelling and representing the desired information. However, the models have to be integrated into a homogeneous domain description. Consequentially, we suggest introducing a three layer concept consisting of: (A) the strategic layer, (B) the tactical layer, and (C) the operative layer (see Table 1).

Issues of context sensitivity in mobile computing

847

3.1.1 Strategic layer The strategic layer defines the boundary conditions of the project by outlining the project aims in a goal function. Goals and their relationships should be described in a formal and definite manner with performance indicators like time, costs, resources, etc. By dividing

Figure 1. Structure of a VO information system. Table 1. Layer concept for a construction project. Layer

Content

Model

Strategic

goals, milestones

goal function

Tactical

formal sequences

workflow-management

Operative

times & resources

scheduling

the goals in sub-goals in accordance with the prqject progress, milestones can be determined. The project manager manages the strategic layer. The strategic layer is the basis of all planning and management activities. It provides general project information designated to the project management. The strategic layer supports the progress monitoring and early detection and prevention of conflicts on project level.

Ework and ebusiness in architecture, engineering and construction

848

3.1.2 Tactical layer By introducing the tactical layer a complex AEC & FM project can be divided into homogeneous, closed phases (milestones). These phases will gather a certain amount of activities (control cycles) required to reach the goals of the strategic layer. The domain manager together with the engineering staff manages the tactical layer. The tactical layer is introduced to specify domain specific activities. The required input and the generated output as well as the responsible actor for each activity are defined. Furthermore, the sequence of activities is defined by specifying the successor and predecessor. 3.1.3 Operative layer While the activities defined in the tactical layer specifying the output needed to achieve the goal of a milestone, the operative layer defines the way how to achieve the goal by considering the given restrictions of the strategic layer (e.g. time, cost, quality). The engineering personnel together with the field workers manage and use the operational layer. The operative layer defines and schedules sub-activities, so called tasks, needed to fulfil the goals of each activity in accordance with the boundary conditions defined in the tactical layer (e.g. time, cost, quality). Resources are planned and the critical path is calculated. 3.2 Developing mobile computer applications using the pattern-based design Establishing the organisational as well as the process structure of a new project requires a lot of efforts and experience of the project manager. However, it is impossible to predetermine each single task needed to complete the project. Predefined process descriptions might be of invaluable help to better describe prospective activities. Homogeneous process descriptions and management guidelines can be made available by developing a so called ‘Process Pattern Library’ (PPL). Such a PPL can be used for the set-up of new (virtual) project organisations. A PPL can be divided into different parts: the concept part, the structures-part, the life cycle-part, the ICT-part and the Facilities part as depicted in Fig. 2. 3.2.1 The origins of the approach Within the EU-cluster project VOSTER the results of appr. 30 EU-research projects in the area of VOs were consolidated and synthesized. A VO core concept and a general modelling framework were developed [VOSTER]. These results were used as the basis for the development of the framework depicted in Fig. 2. Within the next sections selected patterns of that framework are described in a more detailed way. According to Fig. 2 the following patterns will be explained: (1) transparency and self-organisation, (2)

Issues of context sensitivity in mobile computing

lateral VO-structures, (3) continuous architectures, and (5) integrated systems.

VO-structures,

(4)

849

distributed

software

3.2.2 Transparency and self-organisation—pattern To support the VO-approach it is necessary that all partners of a construction project have transparent access to integrated information about construction activities. By applying the ‘lntegrated System’– pattern ‘stand-alone’ applications (e.g. workflow management systems) will be synchronized with each other. Thus, IT-applications remain no longer a singular tool but will support the self organisation process of (virtual) project organisations. A process analysis is needed to get a detailed over-view of the current status and to develop improved, homogeneous activity and information flow-descriptions. The result of this pattern is an optimized, integrated ACTIVITY specification interlinked with an ACTOR-specification and an IT-resource specification. Figure 3 depicts a process description showing ‘errors and omissions registration’ activities by using the ARISmethodology [Scheer].

Figure 2. Framework for VO-Patterns in the AEC & FM sector.

Ework and ebusiness in architecture, engineering and construction

850

Figure 3. Actor-activity information flow.

3.2.3 Lateral VO-structures—pattern Mobile technologies complemented by holistic information systems are used to bridge the gap in the information flow in two ways: (1) across ‘organisational’ levels and (2) across sectorial boarders. On the one hand field workers and engineering personnel can monitor the construction processes in the field. On the other hand, relevant information from the various partners’ information systems must also be integrated into the ‘project information space’. Both forms of data need to be stored and managed in the finest granularity possible. The combination of in-field data acquisition, data consolidation, and data integration bridges the gap in the information flow between the different organisational and sectorial levels. Figure 4 shows the information management in the proposed three layered architecture.

Issues of context sensitivity in mobile computing

851

Figure 4. Layer concept and information management actions & perspectives.

Ework and ebusiness in architecture, engineering and construction

852

Figure 5. Use case diagram—AEC & FM view. 3.2.4 Continuous VO-structures—pattern AEC & FM organisations are mostly project based operated. Therefore, it is essential to support continuous, up-to-date information access as well as information acquisition. For this reason we have developed a common basis of business process descriptions supporting the interdisciplinary knowledge transfer between AEC & FM-actors and actors representing the software engineering sector. Major business processes are described using different representations of the Unified Modelling Language (UML). By representing complex process specifications in multiple perspectives, it becomes possible to consider the various aspects of context sensitive information management in detail. Furthermore, the need for synchronized terminologies of the different sectors and process modelling layers can be addressed. The availability of these patterns will allow for easy and quick customisation of the ‘mobile framework’ to match the project specific needs.

Issues of context sensitivity in mobile computing

853

Figure 6. Sequence diagram— Software Eng. View. One example describing selected ‘Error and Omission Registration’ activities is depicted in Fig. 5 and in Fig. 6. Whereas the first figure represents the end-user perspective represents the later one the perspective of the application developer. 3.2.5 Distributed software architecture—pattern The fragmented organisational structure of the AEC & FM sector requires a distributed data management architecture. Each organisation will store and manage all relevant data in its own IT-systems. Additionally, this information will be interlinked with data from other VO-partners. Project based information spaces can be implemented by introducing a web-portal. This means, the primary organisation-centred information management infrastructure is extended by an (over-lapping), secondary project-centred information management infrastructure. The proposed architecture supports a clear but flexible distinction between the two necessary organisational structures: the ‘internal’, organisation-oriented structure, and the external project or VO-oriented structure. Figure 7 shows the proposed architecture.

Ework and ebusiness in architecture, engineering and construction

854

3.2.6 Integrated systems—pattern Integrated systems and distributed data and information management do not exclude each other. Additionally to the development of the above explained patterns, it is also necessary to integrate technical specifications. This can be achieved by using standardized data exchange formats and their underlying product and process models.

Figure 7. Proposed and partially implemented software architecture. Last but not least, integration of IT-applications will also be achieved by using common design styles and libraries for the development of common GUIs. 4 MAIN-E The multi-dimensional data management approach and the usage of data warehouse technology can compensate the various restrictions of mobile technology, such as: smaller screen size, lower data processing and storage capacity, or smaller bandwidth of wireless networks. MAIN-E consists of a set of technology components supporting CoMoWo, such as a multi-dimensional information framework, intelligent agents, and location based services.

Issues of context sensitivity in mobile computing

855

This will lead to supportive IT-infrastructure providing information on demand and in the right context to the mobile worker. 4.1 Data Warehouse Technology Data Warehouse Technology provides methods and tools to systematically organize, understand, and use complex data. Data warehouses integrate input data from already existing information systems and data collected by (mobile) applications. They consolidate and store data for fast access and retrieval and deliver requested data in an appropriate presentation format. Data Warehouses are based on a multidimensional data model. It is defined by dimensions and facts. The metaphor of a ‘Data cube’ allows data to be modelled and represented in multiple dimensions. Dimensions are defined in Dimension Hierarchies. Dimensions are the perspective with respect to which a user wants to have the data presented or analysed. A formalised description of dimensions is presented in formulas [1] to [6]. Facts are (numerical) values representing quantities by which one wants to analyse relationships between dimensions. A formal fact definition is given in formula [7]. Definition: One schema ‘DS’ of a dimension hierarchy ‘DH’ consists of a partially ordered set of category attributes. ({D1,…, Dn, TopD}; ?) [1] TopD is one specific generic, maximum element, that is functional definable from all other attributes. ?i(1=i=n):Di? TopD [2] Furthermore there exists exactly one ‘Di’, that determines all other category attributes and defines the finest granularity. ?i(1=i=n)?j(1=j=n, i ?j):Di? Dj [3] Definition: The granularity ‘G’ is a subset of the category attributes of all existing dimensions of all dimension schemata DS1,…, DSn DS1,…, DSn G={G1,…, Gn} [4] ?i(1=i=k)?j(1=j=n):Gi? DSj [5] ?i(1=i=k)?j(1=j=k)i?j:Gi? Gj [6] Definition: Facts ‘F’ consist of a certain granularity ‘G’and one specific ‘summation type’.

Ework and ebusiness in architecture, engineering and construction

856

F=(G, SumTyp) [7] 4.2 Schemata and navigation A multidimensional data model can exist in the form of a star-schema, a snowflake schema or a starflake schema. The star schema is the simplest schema, consisting of one fact data table and a set of (smaller) attendant dimension tables. The snowflake schema normalizes some dimension tables and thereby splits the dimension data into additional tables. Starflake schemas additionally allow multiple fact data tables. Figure 8 illustrates how the context aspects defined in chapter 2 are used to define the basic structure of a star-schema. It clearly illustrates how different perspectives on the consolidated central pool of fact data can be defined in order to reflect the various context aspects. Figure 9 depicts a detailed description of the different dimension hierarchies used to describe the context aspects.

Figure 8. Context aspects ordered in a star schema.

Issues of context sensitivity in mobile computing

857

Figure 9. Hierarchies specifying context aspects. Navigation through the different levels of the data cube is called ‘drill down’ (showing more detailed data) or ‘roll up’ (showing data on next aggregation level). The different dimensions generated by the system will be available as pre-processed aggregated dimensions of the fact data (cuboids). Finally, the operations “slicing” and ‘dicing’ enable the presentation (or analysis) of selected parts of the whole data cube. 4.3 Data warehouse extended platform The introduction of a so called Data Warehouse Extended Platform (DWEP) is proposed to support flexible information management. It is depicted in Fig. 10. The data warehouse is the main data source containing and managing all project information. Fast data processing is ensured through the prearrangement of data in appropriate dimensions reflecting the different aspects of context sensitivity.

Ework and ebusiness in architecture, engineering and construction

858

Figure 10. Proposed system architecture, software components, data classification and flow. 4.3.1 Data classification This section classifies and analyses the content of the DWEP with respect to the previously defined context aspects. Figure 10 depicts the following data categories: Planning and Design Data (P), Field Data (F), Externally Collected Data (E), User Access Record (O), and Data Warehouse Meta-Data (M). Planning and design data consists of user data (actor aspect), process definition data (activity aspect), and information about available software tools (IT-infrastructure aspect). Most of this data is already part of the individual, organisation-specific information systems of the VO-partners. Therefore, this information can be collected, consolidated and integrated into the DWEP by semi-automatic mechanisms. Planning and design data can be managed and presented efficiently by developing appropriate data structures and defining improved data management processes reflecting the requirements of the different business processes. Field data is collected on the construction site while monitoring all construction activities, including service processes (e.g. material delivery). It contains information about the status of a specific construction site (time and location aspect), which includes the employees on the site (actor and location aspect), the accomplished and the ongoing construction processes (activity and location aspect), the resources such as equipment or

Issues of context sensitivity in mobile computing

859

material used and available (actor and location aspect), and other spontaneous notes (environmental and location aspect). User Access Records contain information about the access profile of each actor, the requested service and the mobile device that (s)he is using (IT-infrastructure aspect), the construction site described by GPS-co-ordinates (location aspect), the time of the request, and the activity (s)he is working on. External data do further specify the actor, activity, and environmental aspect. The automatic collection of external data supports the user because of reduced necessary input activities. Data collection processes are pre-determined by the specific business process model. Data warehouse meta-data describe the data warehouse architecture which is characterized by dimensions. Meta-data define how to generate, request, modify, store, restore, and delete the various dimensions. Furthermore, meta data contain rules for interpreting the results of the user request profiles. 4.4 Functionalities of the DWEP The functionality of each component depicted in Fig. 10 is briefly explained in the following section. Currently, the agent paradigm is intensively discussed in the literature and used in many software prototypes. Most of our system specifications require software components which must be able to act independently on behalf of the user. Therefore, we have called all of the described components ‘agents.’ However, the authors are aware of current discussions about limitations and negative aspects of the agent paradigm, such as security features. The data collection agent (DCA) is an external, reactive agent and carries out part of the data pre-processing activities of the DWEP. Pre-processing activities cover all the data input and consolidation activities. Two modes of activating the agent exist: first, if the amount of modified data has exceeded a certain limit, or second, if time has exceeded a certain period. The information consolidation agent (ICA) belongs to the core of the DWEP. Its behavior is controlled by using the meta-data of the DWEP. Since real world data tends to be incomplete and inconsistent, information consolidation routines that will attempt to fill in missing values and correct inconsistencies are necessary. The Data transformation agent (DTA) is also part of the core of the DWEP Its tasks are: (1) aggregation, (2) generalization, (3) normalization, and (4) feature construction. Aggregation and generalization reduce the amount of data. Both functions are described in more detail in the section about the dimension generation agent (see below). Normalization will be used to calculate meaningful status descriptions for progress reports instead of presenting total numbers to the user (e.g. work is ‘due,’ ‘overdue,’ with ‘lowerbudget,’ ‘inbudget,’ ‘heavily over budget’). The Dimension generation agent (DGA) is part of the representation layer of the DWEP. To ensure fast data presentation and on-line analytical processing the DGA will pre-compute the cuboids as subparts of the data cube. Depending on the basic technology used, one distinguishes between the relational and the multidimensional approach. Cube aggregation within relational environments uses sorting, hashing, and grouping

Ework and ebusiness in architecture, engineering and construction

860

operations to re-order and cluster dimension attributes. Partial grouping steps are introduced to decrease the computation time of sub-aggregates. The array-based multidimensional approach divides the array into chunks. A chunk is a sub-cube small enough to fit into the memory In a second step, chunks are compressed in order to remove wasted space from empty cells. Furthermore, the order in which cells are visited can be optimised in a way that the number of times each cell must be (re)visited is minimised. The end-user-access monitoring agent (EUA-MA) is the only cognitive agent within the described scenario. It can either be implemented as an external agent or as part of the DWEP. The authors suggest implementing the EUA-MA as an external agent. The EUA-MA monitors all user requests sent towards the DWEP which is only a reactive feature. However, the EUA-MA is able to collaborate with the CDCA (see below). The CDCA is able to interpret the core of the output-request context data. Using this extended context description, the EUA-MA is able to decide whether a new dimension should be generated or not. The context data collection agent (CDCA) is a reactive agent. It is an external agent and has its own knowledge base. Supported by its knowledge base, the agent is able to interpret core context data and extend it with additional information. 5 CONCLUSIONS Mobile computers are a relatively new technology that has not yet been adopted in the AEC & FM industry. The implantation process will require changes in our industry. Even in the basic sciences such as e.g. computer science or human computer interaction many uncertainties still exist on how to apply this technology appropriately and efficiently. This means there exist neither any formalized implantation strategy nor detailed proven ‘rules of thumb.’ The development of context sensitive mobile applications complemented by multidimensional data management technology might be one possible approach for solving some problems related with the usage of mobile devices on construction sites. However, the lack of general design and development criteria leads to the consequence that only by systematic, intensive field-testing of prototypical solutions the advantages, disadvantages, and limitations of mobile computing technology can be revealed. The analysis of these results will lead to the development of new business processes, considering the availability and potentials of mobile, wireless technologies. Finally, it will lead to an integration of wireless and mobile technologies into the core businesses of the AEC & FM sector. To achieve this goal it is absolutely necessary to develop and define guidelines, standards, and specifications for both software development and business process re-engineering. Therefore, the future work of our research group will focus on the integrated work in the areas of business process modelling and software engineering for mobile computer environments focusing on interface design and multi dimensional information management.

Issues of context sensitivity in mobile computing

861

REFERENCES Alexander, Christopher 1977. The Timeless Way of Building—Part 1: Architecture, Part2: Pattern Perception. Oxford University Press. Bürgy, Christian 2002. An Interaction Constraint Model for Mobile and Wearable Computer-Aided Engineering Systems in Industrial Applications. PhD Thesis, Carnegie Mellon University. Camarinha-Matos, L. The virtual enterprise concept, In ‘lnfrastructures for the Virtual Enterprise— Networking industrial enterprises’, ISBN 0-7923-8639-6. Fowler, Martin 1997. Analysis Patterns—Reusable Object Models. Addison Wesley. Jablonski, S., Böhm, M., Schulze, W. Workflow-Management—Entwicklung von Anwendungen und Systemen—Facetten einer neuen Technologie. dpunkt.verlag 1997, 3-920993-73-X. Keller, M., Scherer, R. & Menzel, K. 2002. A personal planning approach for the integration and coordination of multi project process information. Proceedings of the European Conference on Process and Product Modeling, Portoroz, Slowenia. Kurz, A. 1999. Data Warehousing—Enabling Technology. Bonn: MITP-Verlag. Menzel, K., Eisenblatter, K., Keller, M. & Scherer, R.J. 2002. Context-sensitive process and data management on mobile devices. In ECPPM 2002—eWork and eBusiness in Architecture, Engineering and Construction, Turk Z. & Scherer R.J., (ed.); A.A.Balkema. Scheer, August Wilhelm: ARIS Modellierungsmethoden, Metamodelle, Anwendungen: 3. Auflage: Springer Verlag, Berlin: 1998. VOSTER: http://cic.vtt.fi/projects/voster/public.html. (last access June 2004).

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

A context based communication system for construction D.Rebolj, A.Magdič & N.Č.Babič University of Maribor, Faculty of civil engineering, Slovenia ABSTRACT: One of the commonly recognized reasons for a relatively slow application of information technology in construction is that the construction industry has to build its products under circumstances not convenient for appropriate IT support. Conventional computers are ineffective to capture data at places of origin or to deliver or process data where they are really needed. After conducting a series of experimental projects, called e-site, we obtained a firm belief that mobile computing, integrating mobile devices, wireless communication and mobile services, present the missing link in Construction Information Technology, thus providing appropriate information flow in the life-cycle of a building product. Furthermore we came to the conclusion that more effective ways of communication and organization are necessary to exploit the vast quantity of contacts and data that became available through a mobile network. The paper presents an overview on mobile computing in construction, including experiences gathered through the e-site projects, and then continues with the description of a context based communication system that can help to transform the increasing quantity of data into quality information.

1 INTRODUCTION Mobile computing has become an important field in information technology. Specific solutions are being offered to get access to data while outside office, on the road, or on working site, and to feed information systems with instant data from distant locations. Many business fields have been identified where mobile solutions are of high interest. Construction is one of those fields that can gain a lot by applying mobile computing technologies, since the main activity in the building process is taking place in the field, outside of the reach of common information systems. Although quite interesting applications of mobile computing in construction exist, the authors claim that the potentials are by far not exhausted. The term “mobile computing” or “ubiquitous computing” has no clear definition, although some studies have already tried to survey this fast-growing area of information technology. Mobile computing does not only involve mobile computing devices (such as laptops, notebooks, PDAs and wearable computers), which are designed to be carried around, but also the mobile (which in practice means wireless) networks to which these

A context based communication system for construction

863

computers are connected. Specialized services are the third component, rounding out the definition of mobile computing. Although the number of research papers addressing mobile computing is modest, there is no doubt that a great deal of research is still going on, perhaps even too fast for papers to be published. As one technology overtakes another (Jefferson and Orubeondo, 2000; Mobileinfo, 2003), and technical solutions are undoubtedly becoming more consistent and reliable, it is more reasonable to concentrate on general concepts and problems. One such problem is the adaptation of existing information systems suitable for efficient integration with mobile computing. But first of all we have to identify critical problems, for which mobile computing can deliver effective solutions. In this regard, we agree with Vizard that “…until then, mobile computing will just remain a troublesome niche application for those, who can afford to pay for it”(Vizard, 2000). 2 MOBILE COMPUTINGIN CONSTRUCTION In using mobile computing, construction again performs some specific characteristics. The problems are, however, much more common to other field operation industries. One of them, the problem of controlling mobile computers by voice, which is also a requirement for wearable computers, has attracted quite some researchers. In the field of civil engineering, interesting reports can be found for inspection-oriented applications (Garrett and Sunkpho, 2000), and navigation through drawings (Reinhardt and Scherer 2000). In the field of construction, drawings are among the most important types of documents, and therefore software for managing them is a necessary requirement for mobile computing in construction. AutoDesk’s OnSite View offers viewing, mark-up design changes, on-site project document queries using digital measurement tools, and synchronization (Hernandez 2000). Geographic Information Systems (GIS) are already available for some PDAs as well. Project management is another area where extensions to mobile terminals can be very effective (Onsyss, 2003). On the other hand more and more applications are becoming web-enabled (Alshawi and Ingirige, 2003), which automatically extends their usability to browser-supported mobile devices connected to the Internet. EBautagebuch is a web-based punch-list-like application, developed to be used on a PDA for recording activities on a building site (Menzel et al., 2002b). Further applications are related to site inspection and bridge inspection, most of them are specialized on a specific task. Another, more holistic approach originated in Japan, where the Daito Trust Construction Company developed a large-scale mobile computing system called DK Network (Daito 2000). This network consists of specially developed hardware and software components. It remains to be seen how many companies working together on a construction project would be able to follow this approach. For most companies, standard devices, wireless networks and services must be available on the market at affordable prices in order to be attractive. It is, however, perceivable that mobile computing applications are becoming more complex, as for example in the case of pilling operations (Ward et al., 2002).

Ework and ebusiness in architecture, engineering and construction

864

In autumn 2000, a multipurpose experimental-educational research project called Mobile Computing at a Construction Site (or e-site, for short) was launched at the Faculty of Civil Engineering of the University of Maribor (Rebolj et al., 2001). The project has been conducted by the Construction IT Centre and carried out by students and engineers from the construction industry. The purpose of the project has been to answer the open questions of how mobile computing works on site, what organizational changes are required, are the common commercial mobile phone network services sufficient for mobile computing in construction, how complex is the problem of integrating mobile computing into existing information systems (which are still not integrated to the desired extent themselves), and what educational efforts will be necessary. The final test, carried out in 2001 (Fig. 1), showed that the efficiency of information exchange in construction, between the construction participants and within the construction site itself, can be improved significantly even by using current mobile computing components: unmodified, available PDAs, mobile phones and other existing wireless networks, and web services. This project has been continued in 2002 (Magdic et al, 2002) and in 2003. The results proved the high potential of mobile computing for the construction industry.

Figure 1. E-site—experimentaleducational research project 2001. On the other hand, we are faced with another paradox. Currently, many engineers are still using tools that are far from state-of-the-art, but they are very reluctant to change them. This situation is causing an even higher complexity of engineering information

A context based communication system for construction

865

structures today. Existing processes could be rendered much more efficient by altering older information structures to support newer ones, and rethinking the current philosophy of computer use (Rebolj et al., 2002). Despite the availability of hardware systems and high speed wireless networks, we are still lacking software systems designed to support specific on-site tasks, provide helpful guidance through these tasks, and support intelligent methods of human-computer interaction that take into account the context of onsite construction and supervision activities (Menzel et al., 2002). An extended communication system, adaptable to the project and the user is one of the possible solutions to improve existing information systems and to decrease the gap between research in information technology and the state of the practice of everyday work. 3 ESSENTIAL POTENTIALS OF MOBILE COMPUTINGIN CONSTRUCTION Two main aspects exist when looking at any system: the partial and the holistic aspects. In construction this aspects can be defined as “company view” or “project view”, and “personal view” or “actor view”. In both aspects, mobile computing can significantly improve the efficiency of information flows or of information systems. Thus, we have to be aware that mobile computing implies the following facts: • a mobile computer is bound to a specific person • the location of a mobile computer can become a significant piece of information • the mobile computer (and thus the person) is available anytime, anywhere • the person has access to the system anytime, anywhere. These facts are of utmost importance and the basis for the core potentials of mobile computing in construction. From the company (or project) view any information system in use can improve as follows: • information system boundaries extend to the maximum, which means that information will flow to and from the destination/origin points without delays or obstacles • additional information is available from terminal points, like their position, user ID, temperature etc.; in other words, terminals can help applications to become context sensitive. From the personal view following improvements are significant: • the person can be available anytime, according to her/his role in the relevant projects • any other actors in relevant projects are available • personal communication can improve significantly through automatic selection using context parameters (date and time, location, activity etc.). Based on these potentials we have built a concept of a communication system, which uses the core potentials of mobile computing to improve the effectiveness of IT in construction.

Ework and ebusiness in architecture, engineering and construction

866

4 A DYNAMIC CONTEXT BASED COMMUNICATION SYSTEM 4.1 Integration strategies In concepts like mobile computing and ubiquitous computing, space is inherently present (Mitra & Schwartz, 2001). The aim of this kind of computing is a desire to transcend physical distance when accessing or manipulating information. For example, when a foreman makes a decision to solve a problem on a construction site, he needs blueprints at hand and has to update plans to be consistent with the current situation after a change is made. Traditionally, in such situations an individual has to carry all potentially valuable information with her/him, which is practically impossible. Otherwise, the individual should move to some other location where the information is stored. Computers and networks can sort required information, and physical location of the information becomes irrelevant. If mobile computing can help us to overcome the distance between the space where we are located and the space where some valuable source of information is located, we have to be aware of it. Today’s information technology handles this problem and brings new dimension to our lives and to our existing physical space—this is known as virtual space. With this new dimension, our existing space acquires some important shortcuts. This means we can easily shorten the distances of our “travel” if we know how to use these shortcuts in another dimension, in our case through virtual space. In that manner many processes can be optimized for performance and quality. We argue here that today’s solutions are not exploiting these shortcuts. The mapping between real and virtual space must be transparent to be successful. When reducing “distances” in the real world, most systems introduce a new “distance” in a virtual space. By the distance in a virtual space we have several factors in mind that prevent the successftil transfer of information from the information source to the user. For example, different format of data storage and representation, manipulation with communication tools, understanding the real meaning of received information and the context in which it was produced and should be used, to name just a few. Therefore, we recognize the need to change the existing concept of computer use which is a fundamental problem when trying to exploit all the potentials of mobile and persistent computing. The change of this concept is inevitably related to the reorganization of current processes in which computers are used today. Conceptual changes in a networked world should start with the adjustment of inhabitants to new space. People should build a new set of practices that are valid in this space. This should be similar to the practices in real spaces, where a person inhabiting a certain space builds relationships with that space. When someone moves from one space to another, relations with previous and new spaces are changed and people have to adjust and build a new set of practices (Hom, 2000). Introduction of a new—virtual—space requires the same practice. One approach to bridging real and virtual spaces is adopting context aware computing. There are, however, many problems where location awareness is not sufficient. Besides further developments in context awareness in the sense of location, we also see other important factors of context that influence the user and their behavior (Gellersen, 2000). These factors can improve the user’s understanding of available information or help the

A context based communication system for construction

867

user handle the connection, improve data manipulation and solve filtering problems. Hence, more detailed context can bring a higher level of abstraction to mobile devices and make them a better mediator to the virtual world. Similar to how human senses are needed to help people understand and interact with their environment, senses are also needed to understand and integrate virtual space to our lives. There is also a need for new concepts of presence (Kindberg, 2000). If virtual dimension should be fully exploited, real world entities should be present in the virtual dimension as well. In this regard, more explicit representation of material objects and everyday concepts should appear in virtual space. In making this abstraction, the appearance of these objects in reality, whether they are live beings or things or even concepts like roles or processes, is not tremendously important. Our opinion is that it is important to define simple mechanisms for their representation and interaction. For example, each object should have an identity in virtual space. One straight-forward solution to this problem involves the use of Uniform Resource Identifiers (URI). The basis for interaction, communication and grouping can be linked to spatial and other context attributes of real counterparts where this information is easily transferable through virtual space. Methods for context creation become very important here, since they represent a tool for mapping and establishing relations between real and virtual instances of the same object. We can see many advantages as a result of the presence of objects in virtual space in the appropriate context. Appliances are available to users no matter where they are or where they are coming from. Services can better adapt to capabilities of appliances and user needs. All of this considerably improves the mobility ofusers. Having an enterprise environment in mind, virtual space mediates communication over different organizational levels. People can work “closer” to each other in terms of more direct communication. Organization can become structured on a single level, and due to more open communication, risks can be mitigated more effectively From the personal viewpoint all persons needed are “in reach” and therefore information flow can become direct and undisturbed. However, classification and structuring of personal links are inevitable. Work processes can be organized more tightly together, with less “documentation waiting”. Once a document is available to one party, it can be available for all interested parties as well. Parallel processes bring higher productivity to the organization. The same information is not transferred from hand to hand throughout the organization, which is a significant source of errors. The organization can focus on product development and hence make better quality products more efficiently.

Ework and ebusiness in architecture, engineering and construction

868

Figure 2. Dynamic Communication Environment—Integrated views (filtered by selected project/task).

Figure 3. Proposed system architecture. As mentioned before, physical space and distribution of developed products and their producers are not important any more. This means all participants can follow all entities of organizational structure, processes that are performed by the organizational structure

A context based communication system for construction

869

and spatial distribution of products and actors at the same abstract denominator of an object in a virtual space (Fig. 2). 4.2 System design considerations This section discusses the main issues of system design to achieve a dynamic communication environment for construction projects. These key issues include the architecture of the proposed system. However, this paper is not intended to discuss all of the details of the system architecture, instead, it elaborates only on issues directly related to the paper subject. Figure 3 illustrates some major components of the proposed system architecture. From a general sense, the proposed system connects the existing product, process models and project frameworks into the personal communication networks. Process and product models are used as integrators for all the information needed (Tibaut and Rebolj, 2003). In this case, data flow can become fully automated and individuals will not have to worry about which communication link to choose or which file to download or upload in order to exchange the desired information. A user-friendly interface (client software) to such a system is required as well. In order to achieve inter-operability structured information is needed instead of conventional documents and non-standard data formats. New technologies such as the eXtensible Markup Language (XML), XML Schema, SOAP (Simple Object Access Protocol) and XML/Object Serialization have now emerged and could solve problems for future exchanges of information. Their main objective is the development of a system that is not only extensible enough to meet future requirements but is also adaptable and flexible enough to incorporate the new innovative technologies of the future as they emerge. With the availability and the maturity of such technology, heterogeneous systems can share the semantics of information objects by sharing an XML schema that defines the information objects. Between heterogeneous systems, SOAP as an industry standard, can be used as a data exchange protocol. Once a system receives some XML data sets, it can use the XML/ Object marshalling tool to map the XML data set to its internal object model. Thus, with these technologies, a system can manipulate objects from other systems just as if these objects were local to it. However, the most critical issues of implementing these technologies are XML—based standards. Namely, the shared XML schema allows cooperating systems to correctly interpret information exchanged between cooperating companies. Many software vendors have developed and implemented their own proprietary XML schemas. These proprietary schemas may not be compatible with each other. At the industry level, XML-based standards such as aecXML and ifcXML are still under development. Described possible use of XML-related technologies only shows major design considerations that support the proposed system. By reaching into such complex structures as product and process models, getting the parameters that influence the current constellation of a personal communication network can become a complicated task. Therefore, a modular, multi-layer approach is necessary to make the system work. This simply means that the current selection of persons “in reach” can be influenced by more or less parameters. The parameters can either include

Ework and ebusiness in architecture, engineering and construction

870

very specific information on the current activity regarding the process model, and on a current location, which is relevant to the part of the construction site or building (e.g. specific column of a bridge), or just on the person and her or his item in the calendar. The most important part is that the communication system is able to adjust to the information available. 5 CONCLUSION Research and applications in various domains have proved the high potential of mobile computing. In the case of the construction industry this is even more obvious due to the characteristics of a building site. The authors of this paper even believe that mobile computing is the key technology for the IT break-through in construction. The importance of mobile computing is not merely in bringing information to the external terminals of common information systems, or in having this information and the computing power available anywhere and anytime, but in some important new conditions: in the permanent availability of the key project actors in the virtual space. Of course this circumstance should not be abused to the human detriment. Instead, the computer should take the role of a sophisticated assistant and automatically process as much information as possible. For this reason we have integrated existing applications (including the instant messaging service, personal calendar and communication software), common information sources (such as project data, product and process models), and specific “terminal information” (such as location) to build a Dynamic Communication Environment (DyCE) by measure of the human—the actor—involved in various projects and tasks. In this way the mobile computer can really become a sophisticated personal digital assistant (PDA), which will provide the human with necessary information for making good decisions, and to leave the human more time for creative work. From the aspect of a project, this means a much smoother flow of information and thus a higher level of quality. The proposed DyCE concept does undoubtedly represent a much higher degree of IT use in the construction industry, which fits well into the virtual enterprising of the future. REFERENCES Alshawi, M, Ingirige, B.: 2003, Web-enabled project management: an emerging paradigm in construction, Automation in Construction, 12(4), 349–364. Björk, B.C.: 1999, Information Technology in construction: domain definition and research issues, International Journal of Computer Integrated Design and Construction, 1, 3–16. Ceruzzi, P.E.: 1981, The Early Computers of Konrad Zuse, 1935 to 1945. Ann. Hist. Comp., 3(3), 241–262. Daito: 2000, Annual Report 2000. Daito Trust Construction Co. Eastman, C., Augenbroe, F.: 1998, Product modeling strategies for today and the future, Proceedings of the CIB W78 conference, The life-cycle of construction IT innovations, The Royal Institute of Technology, Stockholm, Sweden, pp. 191–208. ELSEWISE [Online], Available: http://www.lboro.ac.uk/elsewise/ [2003, June 27].

A context based communication system for construction

871

Fenves, S.J.: 1996, The penetration of information technologies into civil and structural engineering design: State-of-the-art and directions towards the future, Information Representation and Delivery in Civil and Structural Engineering Design, Civil-Comp Press, Galashiels, Scotland, pp. 1–5. Garett, J.H.Jr. and Sunkpho, J.: 2000, Issues in delivering mobile IT systems to field users. Proceedings: Int. Kolloquium ueber die Anwendung der Informatik und Mathematik in Architektur und Bauwesen (IKM). Weimar. Gellersen, H.W.: 2000, Adding Some Smartness to Devices and Everyday Things, Third IEEE Workshop on Mobile Computing Systems and Applications (WMCSA’00), Proceedings, IEEE press. Hannus, M.: 1996, Islands of Automation in Construction, Construction on the information highway, CIB Publication 198, University of Ljubljana, Slovenia, pp. 20, [Online], Available: http://itc.fgg.uni-1j.si/bled96/ [2003, June 27]. Hernandez, T.: 2000, Mobile CAD goes onsite. Computer applications—mobile computing for construction. Building Design and Construction, 41(9), 19. Hom, S.K.: 2000, Celebrating our emerging voices: People of colour speak: Writing through the frame, with reverence, The First National Meeting of the Regional People of Colour Legal Scholarship Conferences, Boston Third World Law Journal, 20. Jefferson, S. and Orubeondo, A.: 2000, Mobile computing advances on reality. InfoWorld, 22(39), 57. Kindberg, T.: 2000, People, Places, Things: Web Presence for the Real world, Third IEEE Workshop on Mobile Computing Systems and Applications (WMCSA’00), Proceedings, IEEE press. Magdič A., Rebolj, D., Cus—Babič, N., Radosavljevic, M.: 2002, Mobile Computing in Construction, Distributing Knowledge in Building, Proc. of the CIB W78 Conference, Vol. 2, pp. 29–36, Aarhus, Denmark. Menzel, K., Schapke, S., Eisenblaetter, K.: 2002, Potentials of Data Warehouse Technology to Support Case Sensitive Information Representation on Mobile Devices, Concurrent Engineering, Proc. of the 9th ISPE Int. Conference, Cranfield, U.K. Menzel, K., Scherer, R.J., Eisenblatter, K.: 2002, Mobile, wireless, handheld devices to support ework and e-commerce in A/E/C, Computing in Civil and Building Engineering, Proceedings of the 8th International Conference, Taipei, Taiwan, April 3–5. Mitra, A., Schwartz, R.L.: 2001, From Cyber Space to Cybernetic Space: Rethinking the Relationship between Real and Virtual Spaces, Journal of Computer Mediated Communication 7, www.ascusc.org/jcmc. Mobileinfo, Available: http://www.mobileinfo.com/ [2003, June 28]. Onsyss. http://www.onsyss.com/ [2003, June 28].

Rebolj, D., Magdič, A., Čuš Babič, N.: 2001, Mobile computing in construction. Advances in concurrent engineering—CE2001. Proc. ISPE Int. conf., Anahaeim, available under July 28–August 1, Tustin: CETEAM International. Rebolj, D., Čuš Babič N., Radosavljevič, M.: 2002, Discovered and undiscovered potentials of mobile computing in engineering, Concurrent Engineering, Proc. of the 9th ISPE Int. Conference, Cranfield, U.K. SCENIC project [Online], Available: http://cic.vtt.fi/projects/scenic/workpack.html [2003, June 27]. Tibaut, A., Rebolj, D.: 2003, Towards Virtual Product Model, International Journal of Internet and Enterprise Management. 1(2), in print. Turk, Z.: 2000, Construction IT: Definition, Framework and Research Issues, Faculty of Civil and Geodetic Engineering on the doorstep of the millennium, Faculty of Civil and Geodetic Engineering, Ljubljana, pp. 17–32.

Ework and ebusiness in architecture, engineering and construction

872

Vizard, M.: 2000, The way things work is the fundamental problem with mobile computing, InfoWorld, 22, (40), pp. 83. Ward, M.J., Thorpe, A., Price, A.D.F., Wren, C.: 2002, Applications of Mobile Computing for Piling Operations, Concurrent Engineering, Proc. of the 9th ISPE Int. Conference, Cranfield, U.K.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor& Francis Group, London, ISBN 04 1535 938 4

MOBIKO—mobile cooperation in the construction industry based on wireless technology Rasso Steinmann Munich University of Applied Sciences & Nemetschek Technology GmbH, Munich ABSTRACT: MOBIKO1 is one of the lead-projects of the MobilMedia2 campaign of the German Ministry of Economy and Labour. This paper gives an overview on the project and its underlying technology, but is focussing on its specific tasks for mobile applications in the construction sector. The goal of the project is to develop a mobile platform to support the management of contractors in their processes on site. Adapting wireless communication media, the platform will optimise time- and missioncritical processes using mobile communication and mobile collaboration. The project is focussing especially on coordination of workflows, communication of the actors, planning and disposition, quality-assurance and—control and virtual project management. The consortium is combining a strong portfolio of different competences which is the German T-Systems with solutions and services for mobile communication, Nemetschek with software and services in the building and construction industry, conject with virtual prqject spaces and BIBA with scientific background and testing fields. From a technological viewpoint the project is researching in the fields of mobile middleware, IP-roaming, UMTS, LDAP, augmented reality and mobile digital signatures. From an application viewpoint the project is researching in possible future mobile business scenarios in the construction industry, new mobile applications, mobile usability and acceptability. The areas of applications are progress management of construction sites, management of deficiencies, quality control and acceptance of construction work.

1 INTRODUCTION Construction industry in general and under the current economic situation the German construction sector in particular is suffering from increasing complexity, tight timeschedules and budgets on the one side and decreasing profitability on the other side. ICT is offering many opportunities to counter this situation, while huge improvements had been achieved in this field at the level of functionality, workflow support and data

Ework and ebusiness in architecture, engineering and construction

874

integration, during the recent years. Still there is room left for further innovation, especially in the area of data integration. New hope is rising from the benefits which are expected from new approaches in mobile computing. Actors in the construction sector are ready to take care of these new attempts, especially when they feel that mission critical processes could be improved, which are cost- and time-relevant. The MOBIKO-research therefore is following a multilevel approach which is covering application as well as underlying and supporting technology: • MOBIKO is strongly related to future industrial application and therefore the research of adequate scenarios with strong relevance to costs and time is one of the main tasks in the project • Another important task is the usability-analysis of available mobile devices and user interfaces. The construction sector has specific and challenging requirements due to the dimensions of buildings and of their technical documents (plans). Under this aspect also questions of wear-ability, e.g. hands-free data-entry, and robustness are playing an important role. • In huge construction projects in addition challenges are rising from the problem of localization issues on the site and at the same time in the documentation. • More technically MOBIKO is working on server-based services for collaborative scenarios. The tasks 1

MOBIKO Consortium: T-Systems, Nemetschek Technology GmbH, conject AG, BIBA, http://www.mobiko.de/ 2 MobilMedia Initiative of the German Ministry of Economy and Labour, http://www.mobilmedia.de/

Mobile cooperation in the construction industry based on wireless technology

875

in this field are trying to find out the needs where to install servers and to define their specific roles. • A collaboration platform is intended to serve as an infrastructure through which mobile applications used on the construction site are able to share data with their counterparts, the main applications in the office. • Quasi the backbone of the MOBIKO-architecture is a mobile middleware which is offering a series of basic mobile services, which can be used by the mobile applications and server-based applications. Main functionalities of the mobile middleware are mobile availability of IPs (IP-roaming) over the various mobile network services (UMTS, GPRS, GSM, WLAN), secure single-sign-on of all participating applications (based on LDAP) and others. • An additional topic of MOBIKO is a mobile portal, which should serve as an information service for the public.

2 MOBILE SCENARIOS IN THE CONSTRUCTIONINDUSTRY As the usage of mobile technology is fairly new in the construction sector, at the beginning of the project there were only some vague ideas, in which specific scenarios this industry could really gain benefit from it. The result of some research in this area was that quite some fantasy existed on the userside, but it was not sure, whether the considered cases were really adequate. Therefore quite some research had to be undertaken in the definition of user scenarios. Finally, together with potential fiiture end-users it became clear, that the following scenarios raised so much interest, that the end-users, while even not directly involved in the project, agreed to invest resources for the requirements analysis and for future field tests: • Progress-Management • Defect-Management • Acceptance inspection based on augmented reality 2.1 Progress-manager One of the management problems und huge and extended constmction sites, like roadand railway-construction, is the challenge to collect up-to-date information on the current progress of the project and its processes. The consequences are that quite often problems are recognized too late, so that necessary counter measure activities also are undertaken too late. This results into higher cost either for the counter measure itself, or for consequential losses.

Ework and ebusiness in architecture, engineering and construction

876

Another consequence of late knowledge of the project status is, that partial payment is invoiced late, as well, which results into loss of interest. Any day invoices can be made out earlier, means less loss of interest. A new tool, the so called “Progress-Manager” (PM)3, should help in future to support especially these needs: A mobile front-end component of the PM has the role to collect progress data on the construction site and to report back the status of the sub-processes to the back-end part of the PM. While the back-end part is a database application, the mobile front-end is designed to run on mobile devices. Possible candidates are either notebooks and tablet PCs for the cases where also graphical plans have to be displayed or PDAs for the cases, where the status can be reported alphanumerically. The basis of the progress data to be managed by the PM is a concept called “BuildElements”, which helps to define the smallest process-entities which need to be controlled. Build-Elements are also serving as containers, collecting and carrying all additional data needed to monitor the progress status. The source data are coming from legacy applications which are CAD and project management software. For the import of plans an SVG interface was implemented, which

Mobile cooperation in the construction industry based on wireless technology

877

allows to import CAD drawings. For the import of prqject management data, which are in particular processes, tasks and trades, interfaces for the most widely used project management applications in the construction sector (Microsoft Project, Power Project and Primavera) had been implemented. At the start of the controlling workflow, progress data are loaded form the database application into the mobile client. This can either be done by synchronization in the office or also over any TCP/IP network. With this the synchronization can also be done on the construction site, using wireless networks based on UMTS, GPRS or WLAN. The next step in the workflow is the actual controlling on the construction site by assessing the progress of single work-tasks. The collected status can be synchronized back to the data base application, either ad-hoc on the construction site using wireless network in time-critical situations or some times later using a cradle in the office in normal cases. It turned out, that there is a need to get access to the results of the monitoring not only in the office by using the database application but also on any places outside the office. Therefore a web-front-end for the database application was developed in addition, which is accessible on any place, where internet connection is available. Thanks to wireless technology based on UMTS, GPRS or WLAN, nowadays this can be done almost everywhere. 2.2 Defect-manager As a second valuable scenario it turned out, that management and handling of defects gained so much interest, that also for this scenario potential end-users were willing to provide their expertise. It is one of the natures of building projects that unfortunately a lot of defects are caused during the design and construction work. The bandwidth of defects is starting from small scratches and is ending in totally wrongly constructed or wrongly designed parts of a building. In case of big buildings the number of defects are summing up to thousands of issues (e.g. in the case of the new “Reichstag”-building in Berlin, the seat of the German Parliament, over 50.000 defects had to handled). In the workflow of defect management, each issue has to be detected, rated, localized, documented, related to a specific trade, fixed, controlled and its resolution finally accepted. It turned out, that many contractors and controllers already are using database applications for the management of defects, but that the current practice of documentation and localization on the site has a lot of shortcomings, and that data-quality issues caused by media gaps and manually data-reentry, are day-to-day challenges. In the recent time already some mobile defect management application front-ends had been offered, but they were not accepted, because they were too complicated to use. In practice a defect inspector has only some seconds per defect as an average. 3

Progress-Manager is developed by Nemetschek Technology GmbH.

Ework and ebusiness in architecture, engineering and construction

878

Therefore the goal is to find a mobile solution, the so called mobile “Defectmanager”4 (DM), which is accepted due to easy usability and which gets rid of data-gaps and manually data-reentry in the further workflow. The concept, which is widely welcomed by future potential end-users, is to develop a mobile client, which can import the topology of buildings and a catalogue of defect-types ordered by ontology. This front-end has to have an open export-interface, so that the collected defects easily can be sent to the already existing database defect management applications. The mobile client itself allows localizing a defect on the basis of the topology and space-structure of a building. The entry of documentation has to be simple and has to be supported by the catalogue of defect types, so that defects can be described clearly without ambiguity and without using synonyms for the same issue. The building topology and space structure can be imported through XML-data coming e.g. from stateof-the-art building-component-oriented CAD applications. 2.3 Audit manager5 The mobile client application developed for this scenario in MOBIKO is the audit manager6, which represents the mobile client application for construction

Mobile cooperation in the construction industry based on wireless technology

879

site acceptance. The next figure highlights the realized within the audit manager. Construction site acceptance generally is about comparing and documenting the progress of construction projects with the standard conditions and contracts. Because various types of construction acceptance are recognized within the project, different actors are involved according to the type of acceptance. In the audit manager, a mobile collaborative scenario is performed by highlighting the Final Construction Acceptance. The Final Construction Acceptance officially concludes any construction project and is significant for the initiation of the guarantee phase when completed successfully. At the beginning of the process, a wireless connection to the collaboration platform via wireless LAN (IEEE 802.11b) is established. Due to the personalized information of the project manager stored in an LDAP directory on the collaboration platform, a project milestone (generated by the project management client application Progress-Manager) is imported into the audit manager. The project milestone indicates that the construction site. Final Acceptance is due, and additionally has an XML reference to the standard conditions and contract. This information is required by the audit manager in order to automatically generate an electronic acceptance template. The template consists of questions regarding the quality and the dimensions of certain objects within the building. These questions are to be answered by the actors during the acceptance procedure. Eventual insufficiencies are commented and documented electronically by the project manager. The result of the acceptance is an acceptance protocol, list of insufficiencies and (multimedia) documentation. It is quite common for the owner of the building and the project manager have different opinions about the status of a certain object. In such a case, it is likely that a neutral expert or construction authority must be consulted wirelessly per video conference in order to discuss the subject and find a solution. This is a good

Ework and ebusiness in architecture, engineering and construction

880

4

Defect-Manager is developed by Nemetschek Technology GmbH. Hribernik, Kirisci, Hunecke/BIBA/“Mobile Applications for Collaboration in the Construction Industry”, Conference Paper for Mobile Summit 2004. 6 Audit manager is a product developed by BIBA and PRODUTEC Ingenieurgesellschaft mbH & Co KG. 5

example for where mobile collaboration can have a time- and money-saving impact. 3 THE WIRELESS INFRASTRUCTURE AND ARCHITECTURE7 The wireless infrastructure employed in MOBIKO consists of three servers fulfilling specific roles as well as the mobile terminals used by the workers in the field (next Figure). Individually, the servers are: • Central (Mobiko) Server • Construction Site Server • Security Server The Central Server is situated at the headquarters, and hosts the Collaboration Platform as well as the main data storage for the audit manager and Progress Manager. It acts as the central data repository and exchange server for the entire infrastructure. The Security Server may also be located at the headquarters, and hosts the so called “Governikus Intermediar”8 security application, which is used to facilitate the digital signing of important documents generated by the system, such as Final Acceptance Reports. The Construction Site Server is connected to the Central Server either by a fixed wire (e.g. DSL), GPRS or UMTS connection, depending on the construction site’s location. The Construction Site Server forms the heart of actual operations on the construction site, as it provides the basis for the WLAN positioning of mobile terminals on-site by hosting a Positioning Engine, and furthermore represents the major communication node by means of which the majority of information exchange is carried out. The MOBIKO architecture provides a Communication Layer (next figure) consisting of a Web Service9 API covering a wide range of low-level functionality shared by all of the applications contributing to the software suite. It furthermore offers the opportunity for future applications to be quickly and efficiently added to the MOBIKO systems by simply integrating them with the CL. As the CL adheres to the Web Service XML SOAP standard, a wide variety of applications developed under diverse platforms can be coupled to the system.

Mobile cooperation in the construction industry based on wireless technology

881

Ework and ebusiness in architecture, engineering and construction

882

The CL supports the following functionality: • Authentication (Single sign-on) • User management • Project management • Session management • IP-Roaming • Encryption/Digital Signature In order to provide each user with a unique identity across the MOBIKO system, as well as to effect security 7

Kirisci, Hünecke, Hribernik, Dikici/BIBA/ “A wireless solution for Mobile Collaboration on Construction Sites”, Paper on IWWAN (International Workshop on Wireless ad-hoc Networks) 2004. 8 A product of bremen online services Entwicklungs- und Betriebsgesellschaft mbH & Co. KG. 9 Reichmayr, Christian, 2003, Collaboration und Web Services, Architekturen, Portale, Techniken und Beispiele, Springer-Verlag Berlin Heidelberg New York, ISBN 3-540-44291-X.

and user roles and rights management in a user-friendly manner detached from the individual application, these issues are handled by the CL. On the basis of an LDAP directory, both users and projects as well as user roles and rights are stored, managed and replicated across the individual servers and terminals participation in a collaboration by the CL. E.g. if a new user is added to the system in the collaboration platform and a new project initiated on the Central Server, the CL stores the respective data into the LDAP directory which is replicated across the system when the respective devices are next connected. Likewise, the login of a user on a specific mobile terminal is registered and a session established which is recognized system-wide due to the replication mechanism. When considering mobile applications, network roaming is a primary requirement, depending on network availability or individual applications’ QoS needs. The MOBIKO CL fulfils these requirements by providing an open Web Service API for the applicationside control of IP network roaming based on existing IP-roaming products. The basic functionality replaces the terminals’ network layer with an IP-roaming layer which presents the applications with an “always on” situation regardless of the true network status. If the real network status is offline, or the required QoS is not fulfilled by the current network connection, network transmissions are cached until the requirements are met and only then sent. This procedure is invisible to the running applications, which continue to function normally. The user is thus not affected in his work by network status or roaming operations. Finally, the CL also provides all MOBIKO applications with a common, Web Service interface to the digital signature functionality of Governikus (which is located on the Security Server as described above). 4 PROJECT STATUS The project, which started in 2002, is currently in the state of finishing and demonstrating functional models. Big contractors expressed already their deep interest in the results of

Mobile cooperation in the construction industry based on wireless technology

883

this project and offered to provide their requirements in the beginning, and test fields during and at the end of the project. The project will end in 2005. ACKNOWLEDGEMENTS The author would like to express his gratitude towards the German Federal Ministry of Trade and Labour and the associated MobilMedia initiative for supporting and enabling the research underlying this paper. Furthermore, the author would like to thank the MOBIKO consortium as well as its subcontracting parties for their excellent cooperation during the course of the project.

Knowledge management

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Support for requirement traceability in design computing: an integrated approach with building data modeling I.Özkaya & Ö.Akin Carnegie Mellon University, Pittsburgh, PA USA ABSTRACT: In building design computing, there are significant number of applications that provide organization, creation, and storage of requirement information; however, there are few which address the continuity of the information created through requirement traceability. The continuity of information in the context of requirement traceability includes carryover of the information to different design stages, change propagation, update and history tracking. Commercial CAD applications do not provide traceability functionalities and mechanisms for conducting design with a design life cycle approach, spanning from early design phases till post-construction evaluation. Tools that incorporate a data model centered system design have the potential of subsuming advanced design tracking capabilities; however, building data models are often incomplete for handling requirement information and do not provide mechanisms for behavioral operations, like traceability. In this paper, we will present our approach of computational hybrid assistance for requirement management in integrating requirement traceability with design life cycle information management by utilizing building information modeling.

1 INTRODUCTION Requirement traceability refers to the sets of relationships that exist between requirements, design solutions and other products of the design process. Current design computing practice makes only limited use these sets of relationships. There are commendable approaches to structuring the requirement information management process (Kamara et al. 2002, Erhan & Flemming 2004), but their manual approach and lack of overall integration with building models make them expensive and time consuming to use. Most of the existing methods of computational requirement traceability rely on sequential or ad hoc processes. Such processes force the designers to either juggle the requirement information among many applications, or customize generic applications, such as databases or spreadsheets, to fit their needs. The consequences are not only inefficient use of the requirement information, but also bottlenecks in change management, consistency checking and design compliance verification. Introducing

Ework and ebusiness in architecture, engineering and construction

886

requirement traceability tasks to computer aided architectural design environments offers opportunities to overcome these drawbacks (Ozkaya & Akin 2003). In this paper, we present a framework for computational hybrid assistance for requirement management (CHARM) to integrate requirement traceability with a building product data model for design exploration during the early phases of design. CHARM is a process framework which supports designers both in requirement and design spaces, creating a hybrid design exploration space (Fig. 1). The ease of switching between requirement and design spaces is achieved by requirement-design-coupling (RDC). RDC introduces a design space in which requirements and designs interact continuously, augmenting the requirement specification space with the implicit requirements imposed by design solutions. This approach aims to facilitate establishing bridges between requirement and design information, representation and propagation of requirement decisions in design, extraction of information from the building product data model as requirements, and mapping of requirement decisions into and out of parallel design decision domains.

Figure 1. CHARM framework components. In this paper, our objectives are to illustrate requirement relationships which can be utilized for populating building product data models for design information traceability and a flexible system architecture for requirement information management in architectural design computing. 2 REQUIREMENT DATA IN BUILDING INFORMATION MODELS A fundamental problem for requirement management is data representation. A significant amount of research concentrates on building computational data models to solve design

Support for requirement traceability in design computing

887

data and information management issues (Eastman 1999). Many of the data modeling studies target problems of information exchange and design collaboration (Amor et al. 1995, 1999, Bjork 1991, Clayton et al. 1999, Ekholm & Fridqvist 2000, Eastman & Jeng 1999). A building data model is a product model and describes a solution instance. The completeness of the information represented is crucial; however the format of the information is not necessarily in the form of requirements. In a building data model, the product-specific information is specified by design values. While building data models bring uniformity and provide a milieu where building information can be shared, they focus on solution aspects of the building design process. The modeled relationships match closer to design representations, i.e. they are mostly geometric, where as requirements do not always come as geometric constructs. For example, requirements may denote how many stories or rooms a building has, but not necessarily how high it is or its form. Similarly, requirements may specify the purpose of a space, but not necessarily how large it will be. All such correlations require information mapping from requirements to designs. Design information exchange systems with a building product data model enforce the participating applications to commit to a common data model. The common data model makes it possible for the applications to share the information since they use the same input-output mechanisms that are made possible through the data model. There are many advantages of this system design. One is that data exchange and sharing are no longer problems. Moreover, such a scenario structures the domain of the applications that share the data model around a consensus which enforces communication between the fragmented parties. The users do not have to know anything about the structure of the data model. The whole responsibility lies on the application to format the information created during the session in the acceptable structures described by the model. On the other hand, there are some limitations too: a) the successful application of a building data model requires a priori agreement on the domain objects to be used by, including their properties and behaviors, and b) the applications that read and write the data are predefined for successful data exchange. Referred to as the fully integrated approach (Rolland & Cauvet 1992), this approach in which all the subsystems have to conform to the shared model also has integration drawbacks. The data output of other applications are hard to decompose into acceptable formats by specific applications, the model cannot track and coordinate applications that have been applied to the model and most importantly for our purposes, the model cannot carry the historical data and incremental updates (Eastman 1999). These drawbacks also have direct impact on the implementation of information traceability. The inability to trace the applications manipulating the data and the lack of incremental updates break the data dependencies, hence make traceability harder to implement. These limitations are currently circumvented by employing one central model in one phase of building to a central model used in the succeeding phase, for example from design to construction, referred to as the federated approach (Rolland & Cauvet 1992). The federated approach supports using one central model in one phase of building to a central model used in the succeeding phase, for example from design to construction. This approach puts the responsibility of controlling the information to be shared to the specific applications, each of which is responsible of managing its own interactions with the rest of the information sources and targets in the system.

Ework and ebusiness in architecture, engineering and construction

888

Snyder and Flemming (1999) also list robustness of information exchange, semantically correct concept mapping and variable rate of information changes as critical criteria that current building product information models do not address. Snyder and Flemming’s SPROUT approach, which has been employed in the SEED project (Flemming & Woodbury 1995), promotes an information integration environment founded around a schema specification language. In this scenario the subsystems that participate in a collaborative scenario specify their information using the schema specification language constructs. By agreeing beforehand to the subsets of the information that needs to be shared, the subsystems gain flexibility in the remaining of their local functionalities since the schema specification language allows them to augment their local data models without affecting the shared model (Snyder & Flemming 1999). A modeling language based approach allows handling changes to objects over time while maintaining historical records and the specification of behavioral properties like constraints. However, it still needs to operate under a linear scenario where information tracking is not an outcome of the modeling environment, but it is a functionality that the users need to enforce through convoluted and possibly error prone steps. The biggest challenge of building data models—including the most widely used building product data model both in industry and academia lately, the Industry Foundation Classes (IFC) by International Alliance for Interoperability (IAI)—for information traceability is the lack of repeatable and computable protocols to model and trace the information back and forth different stages of design. In the next section, we will exemplify common structural requirement relationships and their modeling counterparts to demonstrate the concepts of repeatable and computable protocols. 3 STRUCTURING THE REQUIREMENT INFORMATION Structuring of requirements is the phase of CHARM in which the relationships between specific requirements of the given design project are formed (Fig. 1). Since designers cannot refer to a complete list of requirements at each instance of the solution path, the tendency is to try to think of general relationships between them. Which requirements can be derived from another? Which are directly affected by a change in the other? Which are independent from the rest? Hierarchy, indexing, classification, association, dependency, and implication relationships aid in building a well-formed structure to capture complex relationships to help address these questions. These relationships also form the paths for tracking the information in the requirement space providing pointers to design instances. 3.1 Examples of requirement relationships The examples we present in this section are selected from the requirements that we elicited during the Carnegie Mellon University, Intercultural Communication Center (ICC) case study. The design problem was to analyze whether the current space allocation of ICC meets the requirements of the services that the center provides. The total area of the four rooms that ICC owns in Warner Hall of Carnegie Mellon University, an office building, is 848 sf. The approximate total area of Warner Hall is 51, 120 sf.

Support for requirement traceability in design computing

889

There are a total of six floors, each of which houses about 25 rooms plus service areas. Scale wise the ICC space corresponds to 1.6% of the total building area; hence is a small scale problem. 3.1.1 Forming hierarchies Forming hierarchies refers to the process of establishing parent-child relationships, which also is commonly known as “is-a” relationship. Requirement A: Classrooms shall have an area between 144 sf. to 400 sf. Requirement B: Tutoring rooms can have the smallest area. Structural Relationship: Requirement B is a requirement A; both specify spatial requirements. The generality of the parent requirement is in defining plausible areas of classrooms. This is further specified by the child requirement for tutoring rooms. They share spatial requirement specifications as their inherited trade. Notice though the parents and children do not need to be both specified quantitatively. Numeric versus string, fixed versus ranges, ordinal versus coordinal values are possible to model when the overarching definition encapsulates the hierarchy semantics, in this case the fact that they are both spatial requirements. The depth of the inheritance tree can grow as much as needed, i.e. the children can also have children in this structure. A hierarchical treatment of requirements, as the example demonstrates, supports the requirement-to-requirement, requirement-to-design and design-to-design relationships to be explored. Consequently, lateral relationships, i.e. relationships on the same level of the hierarchy tree are also possible for requirements. 3.1.2 Indexing In the context of CHARM, indexing refers to metadata about requirements in general such as date created, priority, creator, deadline and the like. It is important to note that these are not simply attributes of a requirement, they may change across prqjects and the user may need to alter their definition. Requirement A: Teaching staff office spaces shall have area between 30 sf. to 144 sf. Requirement A.Priority: Medium Requirement A.Source: ANSI Standards on schools Requirement A.Created by: Ozkaya Structural Relationship: Priority, source and created-by are example metadata categories. The indexes can be user defined. A metadata based approach allows project organization capabilities. For example a decision as “assign all requirements from ANSI standards high priority” can be propagated easily. The priority then can be used in constraint satisfaction. Moreover, the indexes also aid in filtering the information.

Ework and ebusiness in architecture, engineering and construction

890

3.1.3 Classification A class is a defined grouping of entities in which the members fulfill the definition of the class and can be listed. Classification is the process of associating a requirement with one or more requirement classes. Requirement A: In class activities require the students to practice out loud. The neighboring spaces of classrooms should be allocated accordingly. Structural Relationship: Acoustic requirement, privacy requirement, adjacency requirement are possible classes for Requirement A. Classification of requirements enforce a type based structure on the data, hence facilitates the treatment of commonalities between several requirements. A hierarchy of categories can also be constructed. Multiple categories can be assigned to requirements. While classification relationship can be a lower level, application programming decision where classes are predefined, it can also be a run-time functionality to offer flexibility to the users. 3.1.4 Association An association is a simple relationship between two or more entities. When one requirement has, uses, knows about, or is acquainted with another requirement there is an association between these two. This concept is widely used in object-oriented programming. Requirement A: The staff needs a separate working space. Requirement B: Certain activities can share spaces provided that sharing a common space does not degrade the service capacity of ICC for that activity. Structural Relationship: Requirement A is associated with Requirement B; association type: uses. 3.1.5 Dependency Dependencies cover the relationships that may not necessarily be represented by a hierarchy. In conventional requirement management tools, like those used in systems engineering Rational Requisite Pro by IBM, Doors by Telelogic, Caliber by Borland are typical examples, dependency structures are represented as traced-to and traced-from tuples. Further information on how we evaluate requirement management and traceability methods in close disciplines can be found in other publications (Ozkaya et al. 2004). While these provide a mechanism to navigate through the requirement space, they are not always cognitively clear for users. Dependencies that can potentially denote the direction of change are easier to structure; hence make the application more usable. Requirement A: All the teaching spaces should be in close proximity to each other. Requirement B: In class activities require the students to practice out loud. The neighboring spaces of classrooms should be allocated accordingly. Structural Relationship: Requirement A depends on Requirement B; the level of proximity can be defined as a function of the characteristics of the activities.

Support for requirement traceability in design computing

891

The structure referenced here should not be mixed with a building product data model. The dependencies on a building product data model span constructability relationships. Relationships like part-of, is-a, has-a, and associations are the main relationships in this context. These relationships do not always include requirement dependencies which expand on associations as multiple types of associations. Moreover, inverse relationships, e.g. as day light increases artificial lighting should decrease, are not covered directly, but most of the time these are embedded in procedures. These forms of relationships surface more in requirement information structures, which are not necessarily required in building product data models. 3.1.6 Implication Implication is a special form of dependency relationship. Implications are requirements that are not stated explicitly, but emerge as a result of the other conditions imposed on the problem. Implications are very easy to confuse with parent-child relationships. Parentchild relationships involve commonalities to exist in between requirements. Dealing with implications requires active user participation. Requirement A: There is a need for a reception/ waiting area where the students can sign up without interfering with the rest of the activities. RequirementB: Reception, sign up and waiting activities shall be supported. Structural Relationship: Requirement A implies Requirement B (note that Requirement B is not initially given). Another example is: Requirement A: All the teaching spaces should be in close proximity to each other. RequirementB: In class activities require the students to practice out loud. The neighboring spaces of classrooms should be allocated accordingly. Requirement C: The acoustic performance is a function of the proximity of the spaces. Structural Relationship: Requirement A and Requirement B imply Requirement C. Implications also emerge as design progresses and affect the rest of the requirements. All structural component decisions are loaded with implied requirements that the designers not only have to be aware of, but also trace to the rest of the design. 3.2 Modeling implications Forming hierarchies and classification can be modeled as is-a, and categorization of metadata can be covered by has-a relationships. Dependencies are more challenging, they require more input from the designer, therefore, tools to assist dependencies need to build on top of a requirement navigation strategy and associations can be left to the designer to decide. Traceability paths also form during requirement generation tasks. The structural relationships assist in formulating the traceability paths. Table 1 presents these relationships using requirements for an individual language tutoring room as an example. Wherever applicable the relationships are further explained by the commonly known is-a, has-a, part-of relationships. An association covers both part-of and has-a relationships. The both sides of the relationship are not always of the same nature, i.e. in some relationships two requirements are related, in others

Ework and ebusiness in architecture, engineering and construction

892

requirements are related to higher level concepts. This further exemplifies the complex nature of requirements structuring problem. In order to observe the conformity issues of building information models to requirements data we also modeled our example relationships using IFCs. IFCs are incomplete for requirement data modeling; however in our exercise we observed a more compelling outcome in terms of modeling requirements. The requirement information is dispersed into a building information model. While it is possible to package requirements information into a sub-model domain, providing traceability links to other design phases inevitably enforces a dispersed approach where requirements information is represented in conjunction with design information. The user interactions which will facilitate the population of the information model and utilization of this information are critical due to the nature of the situated semantic reasoning involved in modeling requirements.

Table 1. Examples of requirement structuring relationships. Relationship Form

Example

Association

A (part-of) B

Tutoring room is part-of the education wing

Association

A (has-a) B

Tutoring room has-a PC

Hierarchy

A (is-a) B

Tutoring room is-a classroom, a classroom is-a room, a room is-an enclosed space

Classification A (is-a) B

Tutoring room is-a spatial requirement

Dependency

A (depends-on) B

Number of tutoring rooms depend-on number of students

Implication

A (implies) B

Tutoring room implies video-conferencing equipment

Indexing

A (is-referencedby)B

Tutoring room is-referenced-by high priority requirements

4 HIGH-LEVEL SYSTEM ARCHITECTURE In order to support traceability a requirement needs to allow multiple relationships to be represented. This approach combines a data centric representation suggested by the structuring phase of the CHARM framework, with an object-oriented one. Objectoriented modeling does not meet all the needs of the information management problem in architectural design (Amor & Faraj 2001). A hybrid approach where the building data model can be used with more complex data representation schemes provides a richer representation for providing tracing between requirement and design spaces. One of the core challenges of CHARM is the proposed links to design structures using the structural relationships discussed in Section 3.1. Establishing these links requires a flexible, extendible, formal and derivable information structure in order for the designer to build the traceability links with ease. There are parallel information structures to handle the RDC for information traceability within the requirement space, as well as between requirements and designs. One of these data structures is a building product data model, while the other is the requirement data structure. The other components in the

Support for requirement traceability in design computing

893

high-level contextual system description of the CHARM system are a drafting environment, the RDC process integration sub-system, and the requirement manipulation tasks sub-system (Fig. 2). In CHARM, traceability between requirements and designs is achieved by linking a local requirement structure of a project to a corresponding design solution represented in a building product data model. CHARM handles the requirement data within a cyclic graph which can be extended to support user defined relationships. By maintaining parallel data structures, namely the requirement structure and the building product data model, each design solution representation is augmented by its corresponding requirement model. The links between these two data structures are bi-directional; the requirements know about the design instances and design instances know by which requirement structure it was instantiated. The hybrid approach pursued by CHARM where a building product data model can be used with more complex data representation schemes provides a rich information representation domain. This approach has the following advantages:

Figure 2. CHARM high-level system design.

– The selection of the building product data model is not dependent on how well it represents requirements; therefore it brings flexibility to the design environment. – Handling implied requirements no longer depends only on a component based view of the built environment. – The populated building product data model can be referenced based on the requirement information. This approach facilitates increased usability of the data model as design progresses. – Many-to-many relationships can be generated between requirements and design solutions. The designer can interact with the various components of the system such as requirements and CAD domains, or she can interact with the CHARM system as a whole. The purpose of the parallel structures (requirements graph in the requirement data structure and the building product data model) is not to check the compliance of one data

Ework and ebusiness in architecture, engineering and construction

894

structure over the other. On the contrary, the goal is to use them together to ease the shifts from requirements to designs. In fact, this scenario represents a very realistic situation in CAD where not all parties always can agree on a feasible communication model. Similarly, populating a data model is not always the solution needed. Most often, the needs of the users are not limited with data sharing, but also involve the ability to use complex operations during design. Augmenting an existing model with requirement information does not provide the complex tasks to be carried out during requirement traceability. Creating a data model for information exchange solves only part of the problem. It is necessary to use the information that resides in the model in order to test the viability of this information for computational design exploration during early phases of design. Most exemplary commercial applications that use a product data model claim objectorientation to be their governing principles. However, most are in fact “object-based”. That is abstractions to object level representations from the domain of the user are supported, such as wall, door, etc. CAD applications like AutoCAD Architectural Desktop, Microstation Triforma, ArchiCAD and the like are object-based systems (Amor & Faraj 2001). Any data model compliance is an export operation. The users can only benefit from the dependencies supported in the data model during the design sessions if the underlying information framework of the application uses the same logic as that of the product data model. This paradigm is significantly different in truly object-oriented prototypes, where reuse, ftmctionality and inheritance are supported. The designer can utilize the advantages of the underlying data structures for design support. In the CHARM system the RDC, requirement manipulation tasks and the requirement structure are demonstrated using an object-oriented paradigm. The prototype CHARM system needs to interact with multiple components. To demonstrate the interaction of requirements with design, the drawing capabilities of an existing CAD tool can be used. The system design approach can assume a CAD tool to utilize its application programming interface (API) for design components. The core requirements on the CAD tool selection are a flexible API with an object-oriented structure and product data model compliance. Among the CAD tools surveyed the capabilities of Revit is the most suitable for experimenting with parametric design and requirement information, however Revit does not have an API for third party application developers. MicroStation recently switched to a C# based API and is integrating research based efforts, but does not support a core product data model. ArchiCAD is the most compliant CAD tool with IFCs, the most widely used building product data model standard. Its API kit uses the C language, which is not an object-oriented language. The lack of an object-oriented API introduces bottlenecks such as labor intensive mapping modules between different languages, inability to define complex relationships using object-oriented constructs, and being too dependent on the CAD tool of choice. In order to address these challenges and changing CAD scenarios, CHARM system design implements the possibility of integration with a possible prototype design environment as well.

Support for requirement traceability in design computing

895

4.1 Charm prototype system For the prototype implementation, we use a hybrid system architecture, comprising layered and model-view-controller system design styles. A layer is a set of subsystems that share the same degree of generality and interface volatility. Lower levels are general to several applications and must have more stable interfaces, while higher levels are more application specific. The idea is to facilitate those working on higher levels to build on top of the more stable lower levels (Nagbhushan et al. 1999, Shaw & Garlan 1996). In layered systems there is a hierarchical organization where each layer provides service to the layer above it and serves as a client to the layer below. The advantage of layered systems is the high levels of abstraction which allow partitioning a complex problem into incremental steps. Each layer can be composed of multiple sub-systems, which gives an added flexibility to the system. The layered architecture will aid in minimizing the risks of CAD tool dependency.

Figure 3. The layered system design. CHARM system has a five layer system design (Fig. 3). Requirement manipulation, requirement navigation, drafting environment and the building product data model make up these layers. Each of the layers are further structured depending on the functionalities the layer should carry. In strictly layered systems the communication is limited between two adjacent layers; however there can be variations depending on the application domain. In the case of the CHARM system the drafting environment is one of the layers where the strict hierarchical communication schema of a layered system needs to be

Ework and ebusiness in architecture, engineering and construction

896

broken and the CAD application can communicate with the building product data model as well as the requirement manipulation layer. 4.1.1 Requirement manipulation layer The purpose of the requirement manipulation layer is to encapsulate the functionalities for managing requirements information. Requirement manipulation layer is further subdivided into requirement manipulation tasks and utilities layers. The requirement manipulation tasks layer accesses the utilities layer for any realization mechanisms such as consistency checking, traceability path generation, and visualization, to aid information traceability. An important advantage of the layered system design is leveraged in this layer. During low level design new tasks may arise to assist the predefined requirement manipulation tasks (constraint management, tracking, propagation, relationship building, and verification as represented in Figure 1). Or as stated earlier, each task may require multiple sub-tasks, which may share realization mechanisms. For example constraint management and propagation, which are requirement manipulation ftmctionalities in CHARM, both will need to use consistency checking, a realization mechanism which other tasks may also access. The requirement manipulation tasks provide the logic of the requirement manipulation functionalities, while the utilities layer provides the utility services to be used.

Figure 4. Internal logic of CAD application specific layer. Utilities layer contains the algorithmic solutions to achieve the outlined goals for the prototype CHARM application. The services provided in the utilities layer used may be needed to implement several process tasks. New tasks may need to enter the scenario. In addition, alternative routines may need to be employed depending on the devised requirement structure. 4.1.2 Requirement navigation layer The navigation structure layer, the resulting structure of the requirements, serves as the map to move along for the higher level systems. This layer is responsible for the

Support for requirement traceability in design computing

897

requirement graph as well as the process integration through RDC. Similar to the requirement manipulation layer the requirement structure is separated from the RDC implementation to allow flexibility and extendibility. 4.1.3 Drafting environment layer The drafting environment layer is the CAD application-specific layer. This layer is the most unstable layer because there are not true object-oriented CAD systems and they do not integrate information management capabilities. This layer places the integration responsibility on the CAD suite should the CHARM system become a useful extension to CAD applications. There may be multiple possible candidate applications for this layer, each with its own interpreter. The internal logic of this layer would then be as shown in Figure 4. This structure minimizes the integration with any necessary mapping engines and interpreters. The challenges that lie here are mostly CAD application specific issues, which will change with application of choice. While this is not a desirable overhead, it is necessary to test the viability of integrating information management with design. In this design, the CHARM tool will not need to be aware of the CAD tool. This will increase the integrability of the tool with multiple CAD applications. It will also allow the tool to be used as a stand alone requirement manager only relying on the structuring on the explicit requirements, not considering the requirements that emerge during design. This implies that the application could be operated in two modes, one as a stand alone requirement manager, and one as a component of CAD. Such a dual mode operation will increase the usability of the prototype system. When running as a stand alone application the CHARM system can serve as an information management tool. 4.1.4 Building product data model layer The lowest layer, the data model will supply the design information. In the CHARM system an existing product data model will be used because the objective of the project is not to demonstrate a feasible data model, but the goal is to prototype connectivity of requirement and design spaces. Due to its wide acceptance and support in commercial CAD tools we are using IFCs with CHARM. 4.2 Implications of the system design In the hybrid system, each layer needs to provide the view to its neighboring layers, the control for layer specific operations and model for the domain representation of the layer. Hence an internal layer will have two views, one for its server, the layer below, one for its client the layer above. Through these strict separations we aim to facilitate the use of a complex behavior such as traceability over the existing requirement information. 5 CONCLUSION In this paper, we presented our approach to integrate requirement traceability with design computing environments. After briefly presenting the process framework, CHARM, we

Ework and ebusiness in architecture, engineering and construction

898

mainly focused on the requirement relationships that form the core of the traceability functionalities we envision. We described the high-level system architecture we use. We pointed out in our system design the design decisions to facilitate integration of requirement information with existing building information models for achieving traceability functionalities as a behavioral aspect of building information models. Traceability functionalities are centered on the ability to track the decisions both back and forth. When changes occur, traceability allows the notification of the designer, automated propagation of changed values when possible and automated checking for inconsistencies. We envision that the requirement relationship structures suggested by the CHARM framework will provide a structure where tool based requirement traceability can be studied and integrated with CAD environments. We consider the possibility of augmenting computational design with a robust requirement tracing functionality most promising for improving design computation. A sound requirement structure which has design awareness using relationship building, constraint management, propagation, tracking and verification tasks has several immediate contributions to the computational design process. These can take different guises: as a design assistant, as a change manager, as an intent tracker, as a stakeholder communication enhancer, as an error tracker, and as an information navigator. Our future work involves completing the prototype implementation and testing it for viable design scenarios. REFERENCES Amor, R., Augenbroe G., Hosking, J., Rombouts, W. & Grundy, J. 1995. Directions in Modeling Environments. Automation in Construction 4(3):173–187. Amor, R.W., Hosking, J.G. & Mugridge, W.B. 1999. ICAtect-II: a framework for the integration of building design tools, Automation in Construction 8(3): 277–289. Amor, R. & Faraj, I. 2001. Misconceptions about Integrated Project Databases, ITcon journal 6:57– 68. Bjork, B. 1991. Intelligent front-ends and product models. Artificial Intelligence in Engineering 6(1):47–55. Clayton, M.J., Teicholz, P., Fisher, M. & Kunz, J. 1999. Virtual component consisting of form, function and behavior. Automation in Construction 8(3):351–367. Eastman, C.M. 1999. Building Product Models: Computer Environments Supporting Design and Construction , NewYork: CRC Press. Eastman, C.M. & Jeng, T.S. 1999. A database supporting evolutionary product model development for design. Automation in Construction 8(3):305–323. Ekholm, A. & Fridqvist, S. 2000. A concept of space for building classification, product modeling, and design, Automation in Construction 9(3):315–328. Erhan, H. & Flemming, U. 2004. Interactive Support for Modeling and Generating Building Design Requirements. To appear in Akin, O., R.Krishnamurti, & K.P.Lam (eds) Proceedings of Generative CAD Systems Symposium, July 2004, Pittsburgh. Flemming, U. & Woodbury, R. 1995. Software Environment to Support Early Phases of Building Design (SEED): Overview. Journal of Architectural Engineering, ASCE, 1(4):147–152. Kamara, J.M., Anumba C.J. & Evbuomwan, N.F.O. 2002. Capturing Client Requirements in Construction Projects, Thomas Telford.

Support for requirement traceability in design computing

899

Nagbhushan, V., Shiran, Y., Venkatesan, S. & Yehoshua, T. 1999. Nike’s Software Architecture and Infrastructure: Enabling Integrated Solutions for Gigahertz Designs. Intel Technology Journal, http://www.intel.com/technology/itj/q11999/articles/art_1.htm. Ozkaya, I. & Akin, O. 2003. Electronic requirements management: A framework for requirement engineering for iterative design. In B.Tuncer, S., S.Ozsariyildiz & S.Sariyildiz (eds) EIA9: EActivities in Design and Design Education:173–183 Paris: Europia. Ozkaya, I., Akin, O. & Woods, V. 2004. Emerging CAD Processes: An analysis and review of computer aided requirement management. To appear in Akin, O., R.Krishnamurti, & K.P.Lam (eds) Proceedings of Generative CAD Systems Symposium, July 2004, Pittsburgh. Rolland, C. & Cauvet, C. 1992. Trends and Perspectives in Conceptual Modeling. In P.Loucopoulos & R.Zicari, (eds) Conceptual Modeling, Databases, and CASE: An Integrated View of Information System Development: 27–48 New York: John Wiley and Sons, Inc. Shaw, M. & Garlan, D. 1996. Software architecture: perspectives on an emerging discipline, Prentice-Hall Inc. Snyder, J. & Flemming, U. 1999. Information Sharing in Building Design. In G.Augenbroe& C.Eastman (eds) Computers in Building, Proceedings of the CAADfutures ’99 Conference, Boston: Kluwer Academic Publishers.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Interlinking unstructured text information with model-based project data: an approach to product model based information mining S.-E.Schapke & R.J.Scherer Institute for Construction Informatics, TU Dresden, Germany ABSTRACT: Even with an increasing integration of model-based systems with project information spaces, a large percentage of the business and engineering knowledge in AEC/FM is still captured implicitly in isolated and often poorly structured text documents. In this paper we propose a Bayesian Network based mining framework utilising product model data as a primary source of engineering knowledge to support domain-specific information retrieval as well as re-organisation and re-contextualisation of document information. Central to the framework is a four layer Bayesian Network enabling to combine methods for analysing text documents and filtering product models in an evidential reasoning process. Capturing, combining and visualising available analyses results as well as the current mining context, the network allows for explicitly representing the knowledge on document repositories in semantic content networks according to a user’s task and information needs. Furthermore, we expect the mining network, explicitly interlinking document and product model information, to support the understanding of the interrelations among the two domains as well as the exploration of new retrieval, mining and integration approaches.

1 INTRODUCTION In the construction industry most business and engineering knowledge is still captured implicitly, in large project and corporate document repositories. Even with an increasing integration of model-based systems with project information spaces, a large percentage of the information exchange will still rely on isolated and often little structured text documents. Current product model standards such as the IFCs provide classes to reference documents, but the efficient interlinking among the numerous documents and related modelling objects remains an unsolved task. To be able to integrate document information with operational model based information systems there is a need to automatically externalise and track information from common text documents. Numerous standardised document schemata have been developed for exchanging machine and at the same time human readable information e.g. for bidding, tendering and controlling. Furthermore, AEC/FM specific ontologies providing for more detailed content tagging based on common semantics have been explored to more flexibly access

Interlinking unstructured text information with model-based project data

901

document information from applications not directly related to a source document (cf. e.g. Lima et al. 2002, Tolman et al. 2001). Within related domains we expect these structure based approaches to quite successfully allow for exchanging and versioning information among ‘intelligent’ or ‘smart’ documents and corresponding modelbased systems. However, developing expressive and consistent ontologies spanning multiple disciplines as well as monitoring the numerous relations among documents and information models remains a challenging (if at all possible) task. For a flexible and sustainable reuse of information supporting ad-hoc location of information in documents for operations as well as knowledge management, it is necessary to utilise additional context information and appropriate background knowledge. A more detailed analysis of the document content is required in the absence of suitable structure and semantics. Information needs of diverse disciplines, different types of information requests and various mental models need to be considered to effectively retrieve and re-contextualise information from the heterogeneous document repositories in AEC/FM. In recent years several studies have demonstrated the applicability of respective Text Mining techniques in selected fields of AEC/FM e.g. for information and keyword extraction and document classification (cf. e.g. Kosovac et al. 2000, Caldas et al. 2002). However, most of these approaches assume widely harmonised repositories and/or require a great amount of background knowledge and training for single, domain-specific analysis tasks. To externalise document information in AEC/FM practice a flexible framework is required that allows for recognising available context and domain knowledge as well as for combining results of structure as well as context based document analyses at the same time. For information integration with semantic product models both numerical and statistical methods for language processing and knowledge discovery as well as model or even logic based methods for model integration should be supported. This paper presents a probabilistic information mining framework proposed by the authors that first of all allows for recognising product model information as a source of background knowledge in information retrieval. Using a Bayesian Network approach it provides for modelling related probabilistic retrieval, mining and reasoning processes. The framework is not intended to replace existing models optimised for common retrieval and mining tasks, but to represent a common basis to rapidly explore alternative combinations of the available information on the document and its content as well as to integrate additional methods for their analysis. Central to the framework is a four layer Bayesian Network adapted from probabilistic Information Retrieval models developed during the 90s. Capturing, combining and visualising the results of various text and model analyses as well as representing aspects of the current mining context, the network allows for explicitly representing the knowledge on the repository in personalisable semantic content networks. The network first of all provides for retrieving and mining information from documents repositories. However, we expect the explicit interlinking of the document and the product model domain to also support the understanding of the available interrelations and the exploration of new retrieval, mining and integration strategies.

Ework and ebusiness in architecture, engineering and construction

902

2 BAYESIAN NETWORK MODELS FOR INFORMATION RETRIEVAL Bayesian Network based Information Retrieval models provide a theoretically sound and at the same time very flexible framework that allows for recognising different sources of evidence as well as several representation and weighing schemes in Information Retrieval (cf. Turtle & Croft 1991, Baeza-Yates & Ribeiro-Neto 1999, Indrawan et al. 1994, de Campos et al. 2002). Bayesian Networks are directed acyclic graphs, the nodes being random variables of a problem to be solved (here finding relevant information) and the arcs the causal relationships among them (Pearl 1988). The graphs represent knowledge qualitatively, showing the (in)dependencies among variables, and quantitatively, expressing the strength of these dependencies by means of conditional probability distributions. For each node, the parents of that node reflect all its direct causes given by a respective set of conditional probability distributions. From these conditional distributions we can recover a downsized decomposition of the joint probability distribution over all nodes, due to the independencies encoded in the graph. Bayesian Network based Information Retrieval models associate index terms, documents, user queries and user’s information needs with random variables to model the retrieval task as an evidential reasoning process. In this context, the observation of a document, index or query term is considered to be the cause for an increased belief in the respective variable that can be further propagated throughout the network. The first network retrieval model called Inference Network Model was suggested by Turtle & Croft (1991). It is depicted on the left in Figure 1. The static knowledge on the document collection is obtained in a classical indexing process and represented in a document sub-network composed of document nodes dj, text nodes fk and concept nodes ti. On three layers these nodes represent binary variables corresponding to the events of having observed respective documents, text fragments or content elements contained therein as well as descriptive concept representations such as index terms or keywords assigned to the text. The arcs are going from the document to the fragment and from the fragment to the concept nodes, wherever a fragment (or concept) has been observed within the document (or fragment respectively). Correspondingly, binary random variables are used to model the user’s information needs in a one-time query sub-network on two layers. Interconnecting the two subnetworks an information node Ix is depended on query nodes qy expressing the information need and indirectly on the relevance of the corresponding concept nodes. The variables on each of the layers are considered to be independent given the probabilities of the nodes on the preceding layer. In the retrieval process the documents are ranked determining the posterior probabilities at the information node for each single document node having been assigned the status ‘relevant’.

Interlinking unstructured text information with model-based project data

903

Figure 1. Models of Bayesian Network based information retrieval. Most later network models assume the opposite causal ordering. Firstly, it is more intuitive to speak of ‘a probability of a document being relevant given the evidences represented in the network’ than vice versa and secondly only one propagation step is required to propagate the probabilities triggered by a new query throughout the whole network (Indrawan et al. 1994, Baeza-Yates & Ribeiro-Neto 1999, de Campos et al. 2002). One of these latter suggestions is the Bayesian Network Retrieval Model developed by De Campos, Fernandez-Luna and Huete (de Campos et al. 2001, de Campos et al. 2002) and illustrated on the right in Figure 1. In contrast to the preceding network this model does not explicitly represent query nodes. It simulates a query by instantiating the respective concept representation nodes. Several extensions to the basic network model (illustrated by the nodes and arcs rendered in continuous lines in Figure 1) have been proposed by the authors to account for user’s relevance feedback and interdependencies among terms and documents (see items rendered in dashed lines in Figure 1 and cf. de Campos et al. 2001, de Campos et al. 2002) as well as to provide for structured document retrieval (Crestiani et al. 2003). Adapting the node’s probability distributions, Turtle & Croft (1991) have demonstrated that respective retrieval networks can represent different Boolean as well as probabilistic retrieval models using classical Bayesian inference. However, due to the typically great number of interdependent document and term nodes most retrieval systems substitute parts of the propagation process. Equal results are obtained employing

Ework and ebusiness in architecture, engineering and construction

904

a single probability function considering pre-computed index and/or term weights that is called during the propagation process. The concept nodes are typically used to represent classical index terms extracted from the text. However, the concept nodes can also indicate other concept representations such as manually assigned keywords, document type features, related metadata or differently weighed index terms. Conceptually this is a major advantage to the traditional Information Retrieval models in that it allows for considering multiple document representation and weighing schemes in parallel. The above brief discussion shows that Bayesian Network based retrieval models enable flexible storing and interrelating various information and evidences used in Information Retrieval processes. The explicit visualisation of the diverse variables and their influence on the retrieval results supports the understanding of the relations among the text and document as well as the user’s information domain. For these reasons the Bayesian Network Retrieval Model has been chosen as basis for the suggested mining framework described in the following. 3 THE DOKMOSIS MINING NETWORK Central to the suggested mining framework is the four layer Bayesian inference network shown on Figure 2.

Figure 2. Four layer mining network. On each layer a respective sub-network describes the knowledge on a certain domain by a distinctive set of binary variables. The combined network is used, in an evidential reasoning process, to re-configure the collected information to most effectively support various retrieval or mining approaches, i.e. the available structure and context information is canonized and weighted for a combined analysis. The network layers represent the following domains: 1 The product model layer represents knowledge on the product domain acquired from general or project specific product data models.

Interlinking unstructured text information with model-based project data

905

2 The concept layer represents knowledge on the engineering and mining context e.g. acquired through user interaction or provided by AEC/FM specific ontologies and context services. 3 The descriptor layer represents knowledge on the content of AEC/FM documents e.g. their structure, language and elements. It can be built from general thesauri and content schemata as well as from indices of the collection. 4 The document layer represents the knowledge on the specific document collection to be searched for information, which can again be obtained through an analysis of the collection itself. To evaluate the suggested mining network a document and knowledge modelling suite (dokmosis) is being implemented, that integrates several analysis modules to build the respective sub-networks. A first basic network configuration utilising selected text and model analyses is described in the following subsections, discussing the networks’ variables and functionalities in more detail. 3.1 Building the repository network The repository (sub)network is comprised of the document and the descriptor layer. In the basic version of the network it mainly implements the ‘pure’ Bayesian Network Retrieval Model discussed in section 2. It represents the knowledge on the document collection using document nodes dj and fragment nodes fk on the document layer as well as descriptor nodes ti on the descriptor layer. The two layers are built using three text related analysis modules of the dokmosis suite. Firstly, a document collection module provides for importing documents and converting them to a common format based on a small subset of the DocBook specification (http://www.oasis-open.org/). The intention is to preserve basic structural information on sections, headers and figures for subsequent analyses. Secondly, a heuristic fragmentation algorithm is used to compile text paragraphs into equally large, ‘self-contained’ text fragments to allow for more focused information retrieval. The resulting part-of relations are represented by arcs connecting the corresponding fragment and document nodes. Thirdly, the fragment’s text content is pre-processed, performing tokenisation, morphological analysis as well as stop-word removal. Indexing the pre-processed fragments a vector space model considering raw term frequencies is built. Using Boolean, natural, logarithmic or augmented term weighing, the conditional probability distributions of fragment nodes are configured for exact Bayesian inference as follows. Considering all index terms to be equally important we can assume a marginal probability distribution of p(ti=true)=1/M and p(ti=false)=1−1/M with M being the number of index terms for each concept node. For the possible value combinations of all the conditional probabilities p(fk|t1…, ti) are computed by the sum of the respective normalized term weights. Thus, using exact Bayesian inference, for each fragment we obtain the following posterior probability given a query Q and e.g. natural term weighing:

Ework and ebusiness in architecture, engineering and construction

906

(1)

with: wik=(1+log tfi, k) · log idfi tfi, k: frequency of term ti in fragment fk idf: inverse document frequency of term ti It is notable that in eq. (1) also the fragment terms not included in the query contribute to p(fk|Q) with their prior probability. Thus the resulting relevahce for a given fragment only qualitatively matches the respective scalar product calculation used in classical vector model based information retrieval. Considering only Boolean dependencies among the descriptor and the adjacent concept nodes on the left, the marginal distributions can be adopted straightforward when later conditioning on the variables of the concept layer. 3.2 Building the knowledge model network The product model and the concept model layer together represent the configurable knowledge model used to trigger and control Information Retrieval and mining processes. In the basic version, the knowledge model network represents the user’s knowledge by product model classes denoted pm and engineering concepts cx similar to the one-time query network introduced in section 2. The two layers are generated in the following consecutive analysis steps. Firstly, the product model data to be considered is imported, transformed and represented on the product model layer. In the basic version the underlying knowledge model is restricted to a set of classes obtained from a product model server. For this purpose the dokmosis suite integrates a client to the iCSS product model server (iCSS 2002) that has been complemented with methods to identify both the classes defined in an EXPRESS schema as well as those used in corresponding instantiated product models. For each class in the returned set, an independent node is added to the product model layer. Secondly, ontological information is used to derive a discipline specific concept model from the available product model information. For this purpose the dokmosis suite uses an adapted version of the ontology interpreter developed in the EU ISTforCE project that enables translating of model information based on respective engineering ontologies (Katranuschkov et al. 2003). To achieve an easy to process discipline-specific flattened network, the ontological mapping specifications are confined to mappings that filter or aggregate classes from the original set. Thus, for the time being, only Boolean relations interlinking corresponding model and concept variables are represented in the knowledge model network while independence is assumed among all nodes on the same layer. Finally, the specifications have been complemented with lexical descriptors to label each engineering concept with suitable terms. Thus, in the basic network, the concepts essentially represent the names of selected product model classes.

Interlinking unstructured text information with model-based project data

907

3.3 Querying the network To provide for reasoning on the overall mining network the knowledge model and the repository network are interconnected, mapping the concept labels to the descriptor nodes. Again, only Boolean dependencies are considered in the basic network configuration. However, even in this basic version, the presented mining network provides for new possibilities to formulate queries and to express information needs. In parallel to initiating a full text search on the descriptor layer, discipline specific concepts or model classes can be instantiated. Exemplary data models as well as common engineering classification schemes can be used to visualise the indices on the three top layers. Furthermore, the interlinking of the document and the model domain should already supports collecting information elements such as punch list items documenting errors and omissions corresponding to certain building elements for subsequent information analysis and combination. 4 EXTENDING THE MINING NETWORK The described basic mining network can be beneficially extended in several ways. On each layer reasonable representation schemes and typical interdependencies among the variables can be identified to increase the expressiveness of the mining network. Selected extensions, currently under development, are described in the following subsections and shown on Figure 3. 4.1 Extensions to the repository network All three extensions to the repository network target the descriptor layer with the aim to allow for considering additional evidences in the retrieval process. 4.1.1 Considering term interdependencies The first extension to the mining network accounts for term interdependencies in natural language text. The goal is to increase the influence of the comparably few labelled concept nodes and, respectively, the recall of network-based information retrieval. The descriptor nodes ti in Figure 3 illustrate the consideration of undirected dependencies such as term similarities and synonyms in the network. To ensure a directed acyclic graph, the descriptor nodes are duplicated and interconnected one-to-one. Inserting additional arcs and probability distributions the term similarities obtained from thesauri or a term similarity analysis of the collection can be modelled. Directed links for e.g. sub-terms are neglected in this network graph.

Ework and ebusiness in architecture, engineering and construction

908

4.1.2 Considering structural meta-information To be able to account for available structural information on the document’s content, we propose to consider a second representation scheme on the descriptor layer depicted by the nodes sk. Bayesian Networks (or respective extensions) for structured based document retrieval have been proposed e.g. by Piwowarski et al. (2002) and Crestiani et al. (2003), both representing the complete hierarchical structure of the document schema in the network. However, due to the rather diverse schemata used in AEC/FM as well as to limit the complexity of the network the relations among the schema concepts are not explicitly modelled in this representation scheme (in contrast to the previously described term subnetwork). If necessary, indirect relations among fragments and structural concepts can be considered by differently weighted relational arcs. The content meta information provides additional context information on the user’s domain of interest. Moreover, AEC/FM specific content schemata of e.g. specifications, punch lists or protocols can provide for strong evidences that the content obeys certain syntax and semantics to support further information identification and extraction. 4.1.3 Considering entity representations A third representation schema denoted eg is used to represent named entities and content objects embedded

Figure 3. Extended mining network.

Interlinking unstructured text information with model-based project data

909

within the fragments. The entities can be identified through previously assigned labels as well as further content analysis. Due to the limited semantics of most AEC/FM documents, the dokmosis suite implements the following two analyses to recognise entities within the text content. All other content objects such as tables, figures, graphs, etc. are omitted in the current dokmosis version. Firstly, the text analysis module provides for direct, regular expression based entity recognition of persons, organisations, addresses, codes and regulations, scales, formulas. For a given collection this ‘expressions-base’ can be supplemented with additional expressions as well as lexica of e.g. building systems, product names or construction equipment. Secondly, an information extraction module based on the SpecEx Extractor (Grimme 2003) is implemented, that identifies information elements such as actors, tasks and responsibilities within fimctional, full-text work specifications. Supporting the information extractor the text pre-processing of the work specifications includes sentence identification and part of speech tagging as well as the above described entity recognition. Manually labelled work specifications are used to train instance-based classifiers for different named entity types providing for automatic identification of respective information in new documents. This exemplary implementation will provide a first indication of the potentials of respective extractors. 4.2 Extensions to the knowledge network The extensions to the knowledge network aim at providing additional background knowledge as well as for an individual configuration of this knowledge. 4.2.1 Considering instantiated product models Corresponding to the entity representation scheme an ‘object representation scheme’ is introduced on the product model layer. Differentiating between model classes and instantiated model objects, denoted by the nodes pm and on, respectively, more detailed background knowledge on a given project as well as additional retrieval paths can be provided. It seems reasonable to first limit the extension to instance-of relations as depicted in Figure 3. To also consider the various object relations embedded in product models multinomial variables or additional representation schemes would have to be used. Furthermore, comprehensive analyses and information deductions are required to obtain meaningful relations from the product model information, to truly provide for enhancing common Information Retrieval and mining tasks. 4.2.2 Extending the concept layer The main idea of the concept layer is to allow for personalised configurations of the applied background knowledge, without having to change the original model-based information. Thus, distinctive concept nodes are added to the concept model layer for every class and object node, their interrelations being recognised via the corresponding product model root node.

Ework and ebusiness in architecture, engineering and construction

910

As previously discussed, the concept model sub-network is first generated on the basis of pre-defined ontologies, filtering/sortmg/unifying certain levels of abstraction or aggregating classes into more meaningful concepts. However, additional context and user information can also be utilised to re-label classes or alter the discipline-specific concept view. Furthermore, to also consider the influence of discipline-specific aspects without having to rebuild the concept model network, mental models nodes denoted ml may be used as depicted in Figure 3. Duplicating the concept nodes the relevance of each concept node can be conditioned on distinctive mental models representing specific e.g. architectural, managerial or engineering domain views. To reduce the number of conditional dependencies to be considered, only Boolean filters deselecting (or selecting in the case of fewer relevant concepts) inappropriate nodes given a certain mental model will be explored. Again, introducing yet another representation scheme or multinomial variables on the concept layer this approach would also allow for modelling thesaurus-like concept relations such as ‘belonging to the same craft’ or ‘made of the same material’. However, unless such relations are vitally important for a certain mining task, the modeling costs do not seem to be justifiable. 4.3 Querying the extended networks The additional representation schemes provide for numerous new ways to interconnect the variables of adjacent network layers. However, to limit the complexity of the network topology, we first of all focus on two separated retrieval paths as illustrated in Figure 3. Thus, the network based Information Retrieval of the basic mining network using product model classes is separated from the propagation of beliefs on respective instantiated product model objects. Furthermore, we assume the variables of different representation schemes on a layer to be independent among each other given the information of the preceding layers. The explicit representation of modeling objects and text entities very well demonstrates the possibilities but also the challenges of directly interlinking product model and text information. Via the concept nodes product information can be explicitly connected with corresponding text elements to be automatically retrieved from the repository. However, according to the various types of possible objects and entities, a set of similarity measures needs to be established to determine the probability that c-e node pairs really represent the same aspect. Furthermore, the previously applied ontology based transformation to group, abstract or generalize product model objects to more meaningful concepts will greatly affect the possibilities to identify the ‘best matches’ among the concept and descriptor nodes. Even using only binary variables the conditional probability distributions can be used to model different logical operation (mainly ‘and’, ‘or’, ‘sum’) for nodes with multiple parents. Furthermore, the weighing schemes and probability distributions could be optimised to more effectively support subsequent reasoning and mining approaches. Both aspects will have to be further examined when a first mining network for testing has been established. Despite the computational costs of exact propagation we are planning to first of all adopt classical Bayesian inference algorithm to most flexibly explore different mining

Interlinking unstructured text information with model-based project data

911

methods on a small test collection, replacing them with computationally more efficient algorithms when the mining methods are sufficiently tested. 5 CONCLUSIONS Bayesian Network based Information Retrieval Models have been identified to be very flexible technology that allows for representing various information resources and evidences to retrieve relevant Information from documents repositories. We argue that it provides a good basis to utilize appropriate background knowledge and additional context information in the processes of externalising information from respective AEC/FM documents. Extending the query side of the Bayesian Network Retrieval Models to information models of AEC/FM the illustration of respective aspects and concepts supports the domain specific specification of queries and information needs. Capturing, combining and visualising the results of various text and model analyses as well as representing aspects of the current mining context, the network allows for explicitly representing the knowledge on the repository in personalisable semantic content networks. Due to the possibilities to encode the knowledge on the variables in terms of causal relations as well as conditional probabilities the network can be configured to support logic operations as well as numerical mining techniques. This is an essential capacity of the networks enabling to interrelate the ‘rigid’ world of model based systems with the rather fuzzy world of text and language processing. Explicitly interlinking product models and documents we expect the mining network to also support the understanding of the available interrelations among the two domains and to explore new retrieval, mining and integration strategies. REFERENCES Baeza-Yates R. & Ribeiro-Neto B. 1999. Modern Information Retrieval. Wokingham, AddisonWesley, UK. Caldas C.H., Soibelman L., Han J. 2002. Automated classification of construction project documents. In: Journal of Computing in Civil Engineering, Vol. 16, No. 4: pp.234–243. Crestiani F., de Campos L.M., Fernández-Luna J.M., Huete J.F. 2003. A multi-layered Bayesian Network Model for Structured Document Retrieval. In: Proceedings of 7th ECSQARU European Conference on Symbolic and Quantitative Approaches to Reasoning with Uncertainty, Aalborg, Denmark: pp.74–86. DeCampos L.M., Huete J.F., Fernández-Luna J.M. 2001. Document Instantiation for Relevance Feedback in Bayesian Network Retrieval Model. In: Proceedings of ACM SIGIR MF/IR Workshop on Mathematical/Formal Methods in Information Retrieval, Nueva Orleans, USA. DeCampos L.M., Fernández-Luna J.M., Huete J.F. 2002. A layered Bayesian Network Model for Document Retrieval. In: Proceedings of 24th BCS-IRSG European Colloquium on IR Research: Advances in Information Retrieval, Glasgow, UK: pp. 169–182. Grimme S. 2003. Untersuchung des Einsatzes von Methoden zur Informationsextraktion im Bauwesen am Beispiel der Angebotskalkulation. Diploma Thesis at the Institute for Construction Informatics, Prof. R.J. Scherer. Technical University of Dresden, Germany.

Ework and ebusiness in architecture, engineering and construction

912

iCSS 2002. Integrated Client-Server System for a Virtual Enterprise in the Building Industry— Project Description. available under: http://cib.bau.tu-dresden.de/icss/factsheet-en.html. Indrawan M., Ghazfan D., Srinivasan B. 1994. Using Bayesian Networks as Retrieval Engines. In: Proceedings of ACIS 5th Australasian Conference on Information Systems, Melbourne, Australia: pp. 259–271. Katranuschkov P., Gehre A., Scherer R.J. 2003. An Ontology Framework to Access IFC Model Data, In: Electronic Journal of Information Technology in Construction, Vol 8, Special Issue “eWorkand eBusiness”: pp. 413–437. Kosovac B., Vanier D.J., Froese T.M. 2000. Use of Keyphrase Extraction Software for Creation of an AEC/FM Thesaurus, In: Electronic Journal of Information Technology in Construction, Vol. 5: pp. 25–36. Lima C., Fies B., Zarli A., Bourdeau M., Wetherill M., Rezgui Y. 2002. Towards an IFC-enabled ontology for the Building and Construction Industry: the e-COGNOS approach, In: Proceedings of eSM@RT 2002, Salford, UK: pp.254–264. Pearl J. 1988. Probabilistic Reasoning in intelligent Systems: Networks of Plausible Inference. Morgan and Kaufmann, San Mateo, USA. Piwowarski B., Faure G.-E., Gallinari P. 2002. Bayesian Networks and INEX. In: Proceedings of the First Annual Workshop of the Initiative for the Evaluation of XML retrieval (INEX), Dagstuhl, Germany Tolman F., Böhms M., Lima C., van Rees R., Fleuren J., Stephens J. 2001. eConstruct: expectations, solutions and results, In: Electronic Journal of Information Technology in Construction, Vol. 6, Special Issue ICT Advances in the European Construction Industry: pp. 175–197. Turtle H.R. & Croft W.B. 1991. Evaluation of an Inference Network-Based Retrieval Model. In: ACM Transactions on Information Systems, Vol. 9, No. 3: pp. 187–222.\

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Live capture and reuse of project knowledge in construction: a proposed strategy C.E.Udeaja1, J.M.Kamara1, P.M.Carrillo2, C.J.Anumba2, N.Bouchlaghem2 & H.Tan2 1 School of Architecture, Planning & Landscape, University of Newcastle Upon Tyne, UK 2 Department of Civil & Building Engineering, Loughborough University, UK ABSTRACT: Construction projects have intricate supply chains with constantly changing members. Communication of vital knowledge and information between stages in complex projects and across disparate groups involved in these projects offers a significant challenge. As a result, many construction companies have found it very difficult to capture, retain and reuse knowledge efficiently and to then exploit that knowledge in a way that enhances the corporate understanding and experience. Knowledge Management (KM) approach seem to offer real opportunities for improving understanding and knowledge capture and reuse in an effective manner. It provides an infrastructure that enables knowledge to be captured/created, stored, organised and disseminated. The basic purpose in Knowledge Management is to empower the knowledge workers with information/knowledge that allows them to make decision based on a foundation of fact. This paper describes a proposed strategy for the live capture of reusable project knowledge. It is based on research forming part of an on-going project whose primary objective is to develop a methodology for the live capture of reusable knowledge on construction projects (CAPRIKON). The paper starts with a brief review of knowledge management and its application in construction. The ways in which knowledge is captured and reused in real live construction projects is then examined to provide the basis of a conceptual approach for the live capture of reusable project knowledge reflecting both organisational and human dimensions. Managing knowledge will provide considerable benefits in construction projects, but appropriate techniques and technologies are required to promote knowledge capture and reuse. The paper concludes that the capture and reuse of knowledge, will not only prevent the re-invention of the wheel, but could be the basis for innovation, increased agility, better teamwork, supply chain integration, and improved performance in project delivery.

Ework and ebusiness in architecture, engineering and construction

914

1 INTRODUCTION The management of knowledge is becoming a distinct and critical branch of strategic thinking. As organizations seek new ways to attain and maintain competitive advantage, they are looking to exploit to the full their intellectual capital as well as their tangible assets (Elhag et al., 2000). In construction, the knowledge required to deliver construction projects are fragmented; it is held by different professionals who are based in separate organisations. This reflects the nature of the project organisation, which is essentially a temporary multi-disciplinary organisation. Because of these disparate repositories of knowledge, a key aspect of project KM in construction is therefore the capture and reuse of knowledge for the ‘common good’ of the project at different levels and subsequent projects. Knowledge capture and reuse are key elements in project development. Developing a strategy for knowledge capture and reuse is particularly challenging because of the number of special characteristics of the construction project procurement. Amongst these are, particularly, the uniqueness of the projects, its temporary nature, and its complex interrelated activities required to achieve the overall goal (Kamara et al., 2003). This paper describes the proposed strategy for the live capture and reuse of construction project knowledge, doing so by addressing the technological issues. The paper is based on research forming part of an on-going project (CAPRIKON) whose primary objective is to establish a methodology for the live capture of reusable project knowledge in the construction industry that will reflect both the organizational and human dimension of knowledge capture and reuse, as well as exploit the benefits of technology such as Project Extranets (CIRIA, 2002), agent-based systems (Nwana et al., 1997), Case Based Reasoning (CBR) (Aamodt and Plaza, 1994), Data/text mining (Chou and Chou, 1999) etc. In providing a topology of the proposed strategy, this paper explains what project knowledge is and how it is exploited in the construction industry. In addition, it will discuss the key imperatives for KM. This paper presents a proposed strategy of managing project knowledge within the context of capture and reuse. The strategy is based on a project knowledge file (PKF), an integrated workflow system (IWS), and a project knowledge manager (PKM) that can be manual or automated. 2 CONSTRUCTION PROJECT KNOWLEDGE Knowledge is a vital resource in project-based industries and has been described as the product learning, which is personal to individual or organization (Orange et al., 2000). In construction project, it also includes data and information required to conceive, develop, realize and terminate a project. This definition shows that knowledge is a component of a task performing system—that is, a state of the system which warrants task completion and future repetition of this task. Within the construction domain, project knowledge is interconnected and includes knowledge about the end product, the processes involved in its creation and the resources needed. Knowledge requirements therefore includes

Live capture and reuse of project knowledge in construction: a proposed strategy

915

knowledge of participants within a communities of interest that come together to share knowledge that affect the project performance (Ramaprasad and Prakash, 2003). As depicted in Figure 1, it can be explicit or tacit knowledge depending on what circumstances the knowledge is considered or used. This knowledge as identified by Tiwana and Ramesh (2001) can be categorized into three sub-heading. General knowledge is knowledge that people gain through everyday experience and apply it without regard to any specific or direct relation with any task domain. The second is

Figure 1. Tacit and explicit knowledge (Modified from Kidwell et al., 2000). domain specific knowledge, which is gained through study and experience (Court, 1997). In project undertaken, each member of the multi-disciplinary team has domain knowledge that help the organization carry out specific task assigned to them. The third kind of project knowledge is the procedural or process knowledge, this is gained from experience of undertaking a task within the domain. In another context, Tiwana and Remesh (2001) argued that this is a combination of both the general and domain knowledge. Knowledge Management (KM) is becoming increasingly recognized as a critical source of competitive advantage. The way organizations use knowledge is increasingly being recognized as central to performance improvement and construction is no exception. In construction, the management of project knowledge is mostly informal and people-centered, although there is a growing trend towards the development of formal KM strategies within construction firms (Kamara et al., 2002). However, what constitutes knowledge is not particularly well understood. 3 CHALLENGES IN MANAGING CONSTRUCTION PROJECT KNOWLEDGE Several researchers have described project development as a knowledge-intensive activity (Ramaprasad and Prakash, 2003). Project development often involves cross-

Ework and ebusiness in architecture, engineering and construction

916

fimctional linkages, where different participants join a team with different viewpoints. Such teams are often characterized according to the risk and synergy resulting from their interaction with other team members (Huang and Newell, 2003). This interaction brings in the need to organize, integrate, filter, condense and annotate the collaborative data and other relevant information that these team members contribute (Fong, 2003). Creating new knowledge and perspectives is fundamental to project development (Huang and Newell, 2003). A project as discussed above can be considered as ‘a package of features and benefits, each of which must be conceived, articulated, designed, constructed and maintained’ (Hamilton, 2001). The development of this constructed facility can be viewed as a new product development, with customers or end-users purchasing or using the facility (Fong, 2003). Fong (2003) argues that the development of a new product entails the application of knowledge to new problem-oriented situations, thus requiring uncertainty reduction. The same applies to a construction projects, with each project unique in itself in term of design and construction, and the many constraints, the construction industry faces (due to limited space, increasing project complexity, limited budgets, tight programmes and constant demand for facility innovation). Prqject teams are also faced with the challenges to utilize diverse knowledge and create new knowledge in order to meet stringent requirements and fulfill ever-changing needs. Project team members have to incorporate new information into their understanding in order to solve the technical challenges they face. Thus, learning and knowledge capture is inherent in the work they do (project development). In a project based environment, such as construction industry, the need for KM is fuelled by the need for innovation, improved business performance and client satisfaction within the dynamic and changing environment (Kamara et al., 2002). Project based organizations ought to benefit from the inherently innovative nature of project tasks. Since projects characteristically involve the development of new products and new processes, there are obvious opportunities for novel ideas to emerge and for crossfunctional learning to occur, thereby enhancing the organisation’s innovative capacity and potential (Ramaprasad and Prakash, 2003). If this project based activities is managed effectively, knowledge can be used to reduce project time, improve quality and client satisfaction (Love, 2003). Kamara et al (2002) in discussing the CLEVER project identified that among the various initiatives for addressing the challenges facing the construction industry, it is now recognized that the management of project and organization knowledge is necessary if construction businesses are to remain competitive, and adequately respond to the needs of their client. They went on to say that failure to capture and transfer project knowledge, especially within the context of temporary virtual organizations, will lead to reinventing the wheel, which will amount to wasted activity and impaired project performance. The proliferation of research project demonstrates the increasing interest of researchers in both academia and industry in the problems of project knowledge capture. However, the construction industry still has a significant gap to bridge to reach best practice in its use of KM tools. Fundamental changes are required to address the issues evolving from the previous research and applications. The proposed strategy goes a long way to address how the emerging KM techniques and technologies can be deployed to improve knowledge live capture and reuse in construction projects. The next section will

Live capture and reuse of project knowledge in construction: a proposed strategy

917

describe and discuss the proposed strategy, briefly narrating how this strategy will be used to capture knowledge. 4 DEVELOPMENT OF KNOWLEDGE CAPTURE AND REUSE STRATEGY The concept of KM has undoubtedly become a major force in business thinking in recent years. Many large organisations are embracing KM and claiming significant benefits. Nonaka and Takeuchi (1995) and Davenport and Prusak (1998) demonstrated this with multiple examples and claimed that many of the worlds most successful organisations are best at managing their knowledge. However, what is driving this success is how effectively and efficiently various organisations have applied KM tools in their KM strategies. Organisations use a number of methods and tools to support their knowledge. Most of these tools have been developed as part of structured and unstructured technological thrust. Hence a successful knowledge management approach requires correct and effective strategy for it to enhance project performance. The strategy proposed here will enhance collaboration between various distributed project participants and thereby improving live project knowledge capture and re-use. The main focus of this section is to present the proposed KM strategy that will enable live capture and re-use of project knowledge. 4.1 Proposed strategy for live capture and re-use of project knowledge The development of an appropriate strategy for the live capture of construction project will combines both the KM technologies and techniques concepts and tools. The reason for this is that research identifies that there are four main types of knowledge capture as identified in Nonaka and Takeuchi (1995), and it will be impossible to capture project knowledge based on only one approach. The discussion put forward by Nonaka and Takeuchi on knowledge creation shows that project knowledge can be captured as shown in Figure 2. Starting with socialisation, which is the process of converting tacit knowledge into new tacit knowledge through shared experiences in day-to-day social interaction. This can be triggered off within an organisation or external with other team members in a formal or informal manner. In case of externalisation, tacit knowledge is made explicit so that it can be shared by others to become the basis of new knowledge. In a project, this is apparent in informal and formal modes, such as minutes of meetings, workshops presentations, etc. In the combination approach, explicit knowledge is captured from within the organisation or external and then combined, edited, or processed to form more complex and systematic explicit knowledge. This new explicit knowledge is then disseminated among members of the project. The internalisation approach happens when explicit knowledge is captured and shared throughout an organisation or among project participants is then converted into tacit knowledge. This is apparent in project, when knowledge is applied and used in practical situations and becomes the base for new routines. For example, training programs can help team members to understand the project process even better.

Ework and ebusiness in architecture, engineering and construction

Figure 2. Knowledge capture model (Modified from Nonaka and Takeuchi, 1995).

Figure 3. Proposed strategy for knowledge capture & reuse.

Figure 4. Overview of knowledge capture system.

918

Live capture and reuse of project knowledge in construction: a proposed strategy

919

Hence what this research is proposing is KM strategy that view the project knowledge from generic perspective that has all the various types of knowledge capture present and that allow the prqject participant to determine which KM tool that is most appropriate to capture the type of knowledge required. Figure 3 shows a generic view of our proposed environment that will be able to capture any type of knowledge present in a project, be it site knowledge or expert knowledge. The environment will be able to have a structured approach on how this captured knowledge will be re-used. In Knowledge Management environment the realtime capture of project knowledge can be effected through the following: a project knowledge file, an integrated workflow system, and a project knowledge manager. Figure 4 shows an overview of the knowledge capture procedure. During the course of a construction project, learning occurs not only from many critical events but also from the normal day-to-day operations. This learning can be about the facility being constructed, the project process or participants involved in its execution. Within the knowledge capture procedure, the structure of how learning is captured is determined beforehand in the project knowledge file. When a learning event occurs, the integration workflow system is triggered and is sets in motion a flow of actions to capture the learning at a particular point in time. The learning is compiled and edited for reuse within the current project, or in subsequent projects. The learning events can be captured using collaborative learning (Digenti, 1999), Learning Histories (Kliener and Roth, 1996) or CBR. This is quite appropriate to the context of construction projects, where network of organisations is involved in delivering projects. These concepts can therefore be adapted to facilitate the transfer and reuse of collective learning to the individual firms involved in implementing it. Project Knowledge File (PKF)—The PKF will contain information relating to the project knowledge, but will focus on knowledge that can be reused both during the execution (e.g. in subsequent phases), and after the completion of the project The kind of knowledge to be captured and the format and contents of the PKF will be determined through detailed research into reusable project knowledge, but the goal will be to develop an ongoing learning history for the project within a collaborative environment. The PKF will be agreed on by the project participants and they would be required to make contribution to this at a later stage. Integrated Workflow System (IWS)—The role of the integrated workflow system is to implement the PKF in real-time. That is, to facilitate the compilation of the learning history for the project during its execution, in accordance with the parameters set out in the PKF. A generic model will be developed following research into the format and contents of the PKF, but it should be customisable to take into account variations in the PKF. The integrated workflow system is triggered when a learning event takes place. This can be, for example, problems and how they were solved, innovations, breakthroughs or the normal day-to-day operations of a project. When such events occur, the integrated workflow system will request the relevant participants to contribute their views on how various issues were dealt with. A compilation of these different perspectives will form part of the learning history at particular stages of a project, which can either be reused at subsequent phases, or at the end of a project. The trigger for the integrated workflow system can either be automated, done manually by a project knowledge manager, or a combination of both manual and automated systems. An automated trigger requires data and text mining capabilities or other means of detecting,

Ework and ebusiness in architecture, engineering and construction

920

say within a project extranet, when certain events occur. In both automated and manual triggers, server ‘push’ technologies will be utilised to ensure that the required prompt is pushed to relevant participants. The integrated workflow system should also have filtering capabilities to ensure that only the relevant learning is captured to prevent knowledge/information overload. The integrated workflow system can be integrated with existing project extranets or can be developed as a separate application that is compatible with extranets. Project Knowledge Manager (PKM)—This is a role that will be charged with developing and managing the PKF and the integrated workflow system. Again this can be automated using an agent system or manually conducted using a person or persons that will be familiar with the principle of learning histories and how they are developed. 5 POTENTIAL BENEFITS The live knowledge capture system, through ensuring the currency and relevance of the knowledge captured, will have a significant impact on the overall construction project: 1. Construction project team will benefit through the shared experiences that are captured as part of the learning on key events, which can have both short and long term values. 2. Other project teams in an organization can use the learning captured from previous/similar projects to deal with problems they encounter in another project. 3. In the longer term, client will benefit from the increased certainty with which construction organizations can predict project outcomes. 4. Improved project management, as supply chain members would work more collaboratively and share lessons learnt on construction projects. 5. Arguably, construction industry will benefit from an enhanced knowledge base as much learning that is presently not documented can be captured and reused.

6 CONCLUSIONS The work presented in this report shows that there are two main type of knowledge: tacit and explicit knowledge of which all construction project knowledge fall under. In addition, the work presented has divided this project knowledge into three categories: general, specific and process knowledge. The importance of identifying this project knowledge is necessary because this will help capture the relevant knowledge and identify the ones that can be re-used within the project or subsequent project. As KM approach develops and the construction industry moves towards developing knowledge management, as is the trend now, we believe the industry will see an increase in efficiency, quality, and the use of project knowledge. This strategy proposed here, views the whole project knowledge from a generic perspective. It argues that the proposed strategy for the live capture of project knowledge addresses a key problem in the construction industry which had hitherto not been adequately considered. This was due to the absence of support technologies to facilitate the real-time capture of project knowledge, hence the emphasis on post-project reviews and reliance on people. However, with the increasing use of web-hosted project extranets,

Live capture and reuse of project knowledge in construction: a proposed strategy

921

there is now the possibility to make use of this, and other related technologies (such as agent, Collaborative learning and Learning histories) to develop a suitable medium for the live capture and reuse of project knowledge. This proposed strategy will also be a timely addition to current efforts to improve the functionality of extranets (which are mainly document repositories) by incorporating features from tools such as workflow, agents and collaborative learning. However, further work is required to determine precisely the nature and content of the particular kind of knowledge to be captured and what available tools are best suited to capture reusable knowledge. Knowledge Management (KM) is already delivering major economic benefits to businesses as diverse as computer manufacturing, retailers, and construction firms, etc. Properly implemented KM strategy should be implemented across the entire enterprise or project organisation, from initial conceptualisation and design to the maintenance stage. It will become more pervasive in organisations in the coming years, especially as the need for knowledge capture heightens as relevant personnel leave an organisation or move to other projects. It can enhance the project team’s activities by being better able to leverage knowledge internally and externally through improved knowledge capturing and reusing techniques. Ultimately, improvements in the project procurement as a result of KM can reduce the construction period and reduce the cost of projects. However, fundamental changes are required to address the issues affecting efficient knowledge capture and re-use. These issues will be addressed through the on-going CAPRIKON project, exploring how existing KM tools can be used to harness knowledge capture and re-use in a construction project environment. REFERENCES Aamodt, A and Plaza, E. 1994. Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches, AICom—Artificial Intelligence Communications, IOS Press, Vol. 7, No. 1, pp 39–59. Chou, D.C and Chou, A.Y. 1999. A Manager’s Guide to Data Mining, Data Mining, Information Systems Management, Fall-1999. CIRIA 2002. Project Extranets—The Real Benefits, Construction Productivity Network, Members’ Report E2121, pp 1–7. Court, A.W. 1997. The Relationship Between Information and Personal Knowledge in New Product Development, International Journal of Information Management, Vol. 17, No. 2, pp 123–138. Digenti, D. 1999. The collaborative learning guidebook: Learning Mastery, Somerville, MA. Elhag, T.M.S., Deason, P.M., Morris, P.W.G. and Patel, M.B. 2000. Development of a Knowledge System for a Construction Contractor, The PM Institute, New Zealand Chapter Conference, Christchurch, October 26th-28th, 2000. Fong, P.S.W. 2003. Knowledge Creation in Multidisciplinary Project Teams: An Empirical Study of the Processes and their Dynamic Interrelationships, International Journal of Project Management, vol. 21, pp 479–486. Hamilton, A. 2001. Management Projects for Success: A Trilogy, Thomas Telford, First Edition, UK. Huang, J.C and Newell, S. 2003. Knowledge Integration Processes and Dynamics within the Context of Cross-functional Projects, International Journal of Project Management, Vol. 21, pp 167–176.

Ework and ebusiness in architecture, engineering and construction

922

Kamara, J.M., Anumba, C.J. and Carrillo, P.M. 2002. A CLEVER Approach to Selecting a Knowledge Management Strategy, International Journal of Project Management, Vol 20, No. 3, pp 205–211. Kamara, J.M., Anumba, C.J., Carrillo, P.M. and Bouchlaghem, N.M. 2003. Conceptual Framework for Live Capture of Project Knowledge, in Amor, R. (ed.) Construction IT: Bridging the Distance, Proceeding of the CIBW078 International Conference on Information Technology for Construction, Waiheke Island, New Zealand, 23–35 April, pp 178–185. Kleiner, A and Roth, G. 1997. How to Make Experience Your Company’s BestTeacher, Harvard Business Review, Vol. 75, No. 5, (September-October, 1997), pp 172–177. Kidwell, J.J., Vander Linde, K.M and Johnson, S.L. 2000. Applying Corporate Knowledge Management Practices in Higher Education: Colleges and Universities have significant Opportunities to apply Knowledge Management Practices to Support every part of their omission, Educase Quarterly, No. 4, pp 28–33. Davenport, T and Prusak, L. 1998. Working Knowledge, Harvard Business School Press, Boston, USA. Nonaka, I and Takeuchi, H. 1995. The Knowledge-Creating Company, Oxford University Press, UK. Nwana, H.S., Ndumu, D.T., Lee, L.C and Collis, J.C. 1997. ZEUS: A Collaborative Agent Toolkit, Proceedings of the 2nd UK Workshop on Foundations of Multi-Agent Systems (FoMAS’97), pp 45–52. Orange, G., Burke, A. and Cushman, M. 1999. An approach to support reflection and organisational learning within the UK construction industry, Paper presented at BITWorld’99, Cape Town, SA, 30 June-2 July (http://is.lse.ac.uk/b-hive). Ramaprasad, A and Prakash, A.N. 2003. Emergent Project Management: How Foreign Managers can Leverage Local Knowledge, International Journal of Project Management, Vol. 21, pp 199–205. Tiwana, A and Ramesh, B. 2001. A Design Knowledge Management System to Support Collaborative Information Product Evolution, Decision Support Systems, Vol. 31, pp 241–262.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Development of product family structure for high-rise residential buildings using industry foundation classes Toste Wallmark & Mitchell M.Tseng Advanced Manufacturing Institute, Hong Kong University of Science & Technology, Hong Kong, China ABSTRACT: This paper presents an approach of specifying building design through a set of common platforms with defined variations. Both platforms and variations are expressed in terms of product family structures which include modules and components described with parameterized attributes. Furthermore, inter-relationships and constraints among modules and their components are explicitly represented in the taxonomy of the product family structure framework. The motivation of this new approach is not only to develop a concise descriptor of buildings but also to accentuate designer knowledge about product variety and product commonality. To avoid disparity in module definitions, Industry Foundation Classes, has been adapted to represent modules. The ramification of this new approach includes promoting commonality for enhancing economies of scales and offering customized building units through simplified reconfiguration of building modules. The approach is demonstrated by using a high-rise residential building example with adaptation to pre-fabricated construction modules, and its economic benefits are discussed.

1 INTRODUCTION Building design involves translating client requirements to a detailed design specification for construction. Typically, building designers follow an integrated process where architectural designs are detailed and refined gradually with considerations such as structural integrity, safety, and others. This approach is well accepted and widely used in practice, however, there are three emerging trends affecting building design that motivates a reconsideration of different approaches. Firstly, the productivity of building industry has been lagging behind the manufacturing and service industry sectors (Filos 2000). One of the main reasons is that prevailing design practices in the building industry are not conducive to take advantage of repetitions and adapt to economies of scale. For instance, emerging industrialized building methods, particularly prefabrication, have been recognized by several authors with its potential to greatly improve economies of scale and productivity of building systems (Warsawski 1999). However, when using current design approaches, it is

Ework and ebusiness in architecture, engineering and construction

924

difficult to consider modules and commonality in building systems. Hence, the adoption of prefabrication and other industrialized building methods has been sluggish. Secondly, several studies have found that customers are willing to pay more for personalized and customized design of products that are designed to fit their needs, indicating an opportunity for building designers to increase end customer satisfaction by adapting the designs to diverse needs of building users by offering variety options to customers. For example, Filos (2002) argued that buildings should be made to suit people e.g. relevant to the market and adaptable across sectors. Last but not the least, there is a trend in the building design profession, CAD/CAE software industry and related community indicating a strong demand for information and knowledge sharing and reuse. Such reuse can reduce errors, improve design quality and shorten the design time. The development of IFC, Industry Foundation Classes, (Wix & Liebich 2001) is an important contribution supporting designer collaboration through standardized model-based exchange of building design data across applications. Still, knowledge reuse often fails in practice due to a lack of technical and organizational mechanisms (Fruchter 2002). Considered jointly, these trends reflect a growing need for a new building design approach that includes commonality, modularity and variety inherently in its methodology, process, tools and information systems. In essence, the commonality, modularity and variety of customers’ needs, designs, tools, materials, tools, equipment and knowledge needs to be captured, shared and re-used. The foundation for this new approach lies in the development of proper design descriptors that can represent common structures and variety options within a coherent product family structure for the building industry. 2 PROPOSED FRAMEWORK The proposed framework originated from results of research and development projects in the manufacturing industry where management of product variety has been considered an important driver for productivity improvements. (Jiao et al. 1998 and Du et al. 2002). Particularly, development of ‘product platforms’ (Ulrich & Eppinger 2004) and ‘product families’ (Meyer et al. 1997) has been well accepted in product design as means of systematizing management of product variety. Simpson et al. (2001) provides an overview of approaches to product platform design. Meanwhile, approaches of developing rigorous representations of product platforms and product families for the building industry have not been reported. We focus our approach on the development of product family structure to represent physical design across building projects by highlighting the product variety The emphasis is thus on the physical domain of design, as described by Suh (2001). In essence, buildings will be described in terms of a specific base product and associated variant modules. Both of them are derived from a physical building family framework which represents the share commonality to accentuate the product variants aspects. In the following sections, details of frameworks and approaches will be discussed. An application in high-rise residential buildings will be presented as an illustration.

Development of product family structure for high-rise residential buildings

925

2.1 Development of framework Issues of characterizing and representing a product family has been addressed by Du et al. (2000, 2001) using the concept of Architecture of Product Family, APF. In order to develop the framework for representing physical design variety of the building product family, the engineering view of the APF is applied. This adaptation of the APF framework allows us to depict building designs through a set of expressions describing a base product and its allowable variants for building product families. Based on this adaptation, the fundamental aspects of the building family can be developed. Furthermore, we assert that the base products and variants can be expressed in terms of a set of well defined modules. In order to unify the definition of modules to avoid dispersions of different decompositions, the Industry Foundation Classes (IFC) standard was chosen in this approach. IFC has been recognized as the major initiative in modeling building structures with clear definitions of components and interrelationships. IFC has been adopted by several CAD/ CAE vendors, further reinforcing the support of IFC in industry.

Table 1. Terminology of product family structure inbuilding. Product family construct

Building family structure

Base product

Common building modules

Modular variants

Distinctive building modules with adjustable design parameters

Variety taxonomy

Module inter-relationships

Combination constraints

Include conditions parameter constraints

After the building family structure is characterized, an object-oriented model representing the constructs of the family is proposed. 2.2 Characterization of building family structure When the product family structure is applied to the building domain, it is referred to as Building Family Structure. In order to develop a model of the Building Family Structure, the required constructs are first identified. Based on the engineering view of APF, the product family structure captures design knowledge of modular variety using four constructs as shown in Tablel. By applying the constructs of product family structure, variety aspects of the product design, building product variety in this case, can be made noticeable. In building construction, the visibility of product of variety and commonality could lend itself to many applications such as bill of materials aggregations, design reuse and other applications. To incorporate this information, several knowledge sources have to be surveyed, with respect to the content classification of the building family structure. Table 2 provides examples of such knowledge sources for building product family.

Ework and ebusiness in architecture, engineering and construction

926

The base product of the building family captures the concept of shared designs across variants of the building family. It often can be expressed as a collection of modules with common relationships. Modular Variants are characterized as parts of the design that can be combined into unique buildings with the base product. The interrelationships between the base product and its modular variants are termed variety taxonomy. Details of the allowable combinations modular variants with respect to the base product are classified as combination constraints under the framework.

Table 2. Knowledge sources for building family structure. Building family structure

Examples of knowledge sources

Common building modules

Frequently used physical building structure modules e.g. repetitive prefab. elements

Distinctive building modules

One-of-a-kind/rarely used physical building modules

Module inter-relationships Overall organization of physical building modules Adjustable design parameters

Physical design freedom within developer’s configurable modules

Include conditions

Technical criteria for allowing use of a distinctive module

Parameter constraints

Physical limitation of parameters

In the application of product family constructs in building, the following terminologies and concepts are proposed. Building Modules are defined as a separate design structure with its own integrated building model which is defined using the IFC specification. Building modules thus have their own separate physical representation, independent of other modules. Common building modules are modules that are always included in every variant of the building product family. These modules thus give the building systems economies of scale across projects through re-use of components and process repetitions. Common modules will thus be included whenever technically necessary and when developer needs are similar across projects i.e. to provide common features. The ability to re-use common modules contributes to lowering the construction cost when economies of scale apply. In contrast to common building modules, distinctive building modules are defined as modules that are not necessarily included in particular variants derived from the building family, typically used on a one-off basis, such as for a particular project or developer. Common and distinctive building modules are related using module interrelationships, based on definitions of module boundaries. Using these relationships, distinctive building modules are combined with common modules to create unique designs. Modules are configured through their adjustable design parameters. These parameters allow changing the design without affecting the integrity of the overall product structure.

Development of product family structure for high-rise residential buildings

927

To achieve integrity of building product family designs, knowledge of include conditions for building modules that constrains the usage of particular modules

Figure 1. Relationships between the building family structure modules, IFC models and the internal IFC objects. and parameter constraints should be included. For instance, include conditions would be required to enforce inclusion of a distinctive module under certain conditions to ensure that constraints such as structural engineering considerations and building regulations are complied with on the modular level of the building family design. 2.3 Buildingfamily module representation Classifying the IFC model as a specification of components, particularly classes under ‘lfcBuilding Element’ e.g. ‘Column’, ‘Wall’ and ‘Ramp’. Combinations of such

Ework and ebusiness in architecture, engineering and construction

928

components are here defined as building modules as illustrated in Figure 1. This and subsequent family representations are based on object-oriented modeling represented using Unified Modeling Language (UML) notation (Rumbaugh et al. 1999). With the structure presented in Figure 1, IFC models are defined separately from building modules so that they can be handled more independently. The collection of IFC objects i.e. any object with IFCRoot as super class is aggregated under an IFCModel. The IFCModel thus holds the representation of all physical details of each module through its internal IFC data structure. Adjustable design parameters of a building module are exposed by the BuildingModule and maintained internally by IFCmodel that implements the constraint relationships from the parameters to its IFC objects.

Figure 2. Representation of modular structure of the building product family. 2.4 Building family representation For building, Sarja (1998), refers to an open modular system as one where modular parts at different hierarchical levels can be used to produce different interchangeable products and designs that can be joined together according to connection rules to form a functional whole. In order to describe the building module system and the structural relationships for the distinctive building modules, the overall modular system for the building module family can be represented as a hierarchical structure, based on the Generic Product

Development of product family structure for high-rise residential buildings

929

Structure, GPS, described by Du et al. (2001). GPS compound modules can be decomposed into either compound or primitive modules. Inclusion of modules can either be enforced or optional, and for primitive modules, XOR inclusion can be enforced e.g. one an only one out of a set of options must be chosen. Figure 2 shows an object-oriented representation of the GPS applied to represent the module family concept of building. The building family structure is identified through its top module, which is a compound module. XOR-optional modules can be specified under primitive modules by using inheritance and defining the primitive module as an abstract class. Hierarchical decomposition is implied by the use of recursive aggregation of compound modules. The constraint governing compound/primitive module combinations is given in Figure 3. 2.5 The modulus aspect in modular building family The representation of modularity for a building family above resembles the characterization of modularity by Ulrich & Eppinger (2004) under their first two modularity types; slot-modular and bus-modular. In slot-modular architectures, modules are attached to

Figure 3. Modularity structure constraint on multiplicity. slots, where all bus slots are different. In bus-modular architectures, all slots are of the same type. The third category, sectional-modular, refers to architectures where modules can be attached if their sections have an identical interface e.g. contour or dimension. Sectional modularity refers to a commonly used notion of building system modularity, namely the modulus aspect e.g. the modular dimension of building elements, characterized by Hop (1988) as ‘a coordinate system that makes use of standardized material units without waste’. It should be noted that there is no inherent conflict between these modularity types, and all can be combined favorably in the same building system. In particular, in the representation of the building module family developed above, dimensional aspects of modules are considered as details within modules. Under the building family structure, the modulus metric of a module can be exposed as a module parameter, which allows catering for this dimensional aspect of building design modularity.

Ework and ebusiness in architecture, engineering and construction

930

2.6 Building family constraints representation Product modeling with respect to design constraints has been discussed in building research by several authors, e.g. Santos et al. (2002) and Liebich et al. (2002). In our approach, the focus is to represent design variety constraints on building modules to accurately model variety. Object Constraint Language, (Warmer & Kleppe 1999) is adopted here to perform this specification. OCL Constraints can be specified for any module for their attributes as well as internal IFC models, and OCL thus serves to map parameters across model layers. As an example of a specific constraint on a generic module, consider Figure 4. ‘CompoundModule’ represents any compound module for which a parameter moduleDoorWidth is defined using the IFC type ‘PositiveLengthMeasure’. This exposed parameter is mapped to the internal IFCModel through the topmost OCL constraint in the figure. For the internal IFC model, all IFC objects that are instances of ‘IFCDoor’ must then conform to this measure in their internal structure. The expressive power of the constraints is only limited by the capabilities developed under the OCL specification.

Development of product family structure for high-rise residential buildings

Figure 4. Example of the application of OCL to represent building family constraints for the internal module structure.

931

Ework and ebusiness in architecture, engineering and construction

932

OCL can also be used to describe constraints that apply on parameter values between modules in the product family, similarly as above. These constraints may also apply to internal structures of the module, if values of those structures are exposed externally. In this case, the constraints are defined on the module parameter, based on the IFC model value, which in turn is constrained by internal IFC structure values, all by using OCL as the definition language. A combination of these constraints can serve to further refine the variety design of the modular building product family structure. 3 PRODUCT FAMILY STRUCTURE FOR HIGH-RISE RESIDENTIAL BUILDING High-rise residential building is a building type where possibilities to achieve economies of scale through re-use of modules exist, particularly when modules are re-used across projects. Developers typically seek to adapt the composition of flat units of the building to the expected market conditions by requesting design changes throughout the project. In order to cater more efficiently for such changes, as well as modular construction techniques and principles, the concepts of a product family structure is proposed and exemplified in this project. Table 3 outlines the major aspects of the building family structure in high-rise residential building and relevant knowledge sources.

Table 3. Building family structure applied to highrise residential building. Building family structure

Examples of knowledge sources

Common modules

Core, pre-cast façades and staircases

Distinctive modules

Apartment assemblies

Modular relationships

Core-apartment relationships

Adjustable parameters

Core section dimensioning

Include conditions

Structural engineering requirements

Parameter constraints

Building regulations

Development of product family structure for high-rise residential buildings

933

Figure 5. Typical floor plan of Fu Tei high-rise residential development project. (Wong (proprietor), Patent No. 1021475). For high-rise buildings, locating the core in the middle of the ground plan is advantageous from a structural reinforcement point of view (Eisele & Kloft 2002). This principle is one of the aspects that have lead to the development of modular designs used in a current housing development project in Fu Tei in Hong Kong. The Fu Tei project design illustrated in Figure 5 thus features a number of modularity for high-rise building with extensive use of pre-cast methods. Around a cast-in-place core, pre-cast concrete modules are used in the apartment wings, thus forming the basis of a modular system of core, apartments and pre-cast modules for each storey. This geometrical repetitiveness of the apartment modules is evident in Figure 5. An exterior view of the actual building being erected with the floor plan in Figure 5 is shown in Figure 6. In the application of the developed framework, the above facets of modular residential high-rise building designs used in the Fu Tei project are considered as follows.

Ework and ebusiness in architecture, engineering and construction

934

Figure 6. External fagade view of Fu Tei project high-rise residential building in Hong Kong. Figure 7 illustrates the application of building family structure for high-rise residential building. Here, common modules include pre-cast components used for all cores and apartments within the building family. The top module represents the whole building, consisting of two compound modules, the nonresidential structure and the storeys. Multiplicities indicate which and how many modules that will be included in the base product. Major modules are core and flat modules, which form the storey module. For each project, distinctive compound core and apartment modules can be chosen. The only free variety parameter in this case is the multiplicity of the apartment storey class under the overall storey module. For particular choices of compound modules, different uses of primitive modules, particularly pre-cast ones can be determined. In this example, different choices of core and apartment imply different usage of staircase and façade precast modules. In this family structure, one option is to select how many fire and apartment storeys as well as which core and flat types to be used. While each apartment storey only has one core module, there are eight flat units per storey, and for each such flat, two different types can be selected. Based on this family approach, selections of a particular core and flat determine repetition of different pre-cast modules. In the family in Figure 7, selection of a particular core and flat mix will influence the

Development of product family structure for high-rise residential buildings

Figure 7. Building family structure for high-rise residential building. ‘compoundModule’ and ‘primitiveModule’ are left out on lower levels for brevity.

935

Ework and ebusiness in architecture, engineering and construction

936

number of pre-cast staircase and pre-cast façade modules that will be included, as expressed by the multiplicities of the pre-cast modules for various options of core and flat. Table 4 summarizes a set of example constraints enforced on the model of the product family structure, which are applied as follows. An inclusion constraint for the building family is enforced for fire safety storeys. Fire safety storeys are used in residential highrises for shelter in case of fire. Assuming that there must be one fire safety storey for every 20 apartment storeys to accommodate residents safely, the constraint on the fire safety storey inclusion can be defined in the context of ‘Storeys’ as “storeys.fire>size=(storeys.apartment->size).div(20)+1”. The lowercase initial indicates the association name of the class with the same name starting with uppercase to be navigated to in the constraint e.g. ‘apartment’ navigates to ‘Apartment’ from the ‘Storeys’ context.

Table 4. Summary of constraints enforced on the high-rise product family structure on Storeys context. No. OCL invariant constraint expression 1

self.fire->size=(storeys.apartment->size). div(20)+1

2

if self.coreType=‘A’then apartment.core->forAll (oclIsKindOf(CoreA))

3

if ((apartment.flat.select->(self.oclIsKindOf (FlatB))->size)>120 then apartmentcore.forAll (self.isKindOf(CoreA))

Under the building family structure in Figure 7, it is also possible to change between ‘Core A’ and ‘Core B’. Typically, this should not be allowed, as the core is generally designed as a repetitive structure intended to be the same for all floors. To enforce a such constraint, the core type could be defined as an primitive module of attribute of Storeys and constraints could be added, e.g. for the context of ‘Storeys’, “if Storeys.coreType=‘A’ then apartment.core->forAll (oclIsKindOf(CoreA))”. For instance, if we determine that the use of more than 120 type B flat requires usage of Core A due to structural engineering requirements, this can be enforced in the ‘Storeys’ context using “if ((apartment.flat.select->(self.oclIsKindOf(FlatB))->size) >120 then apartment.core.forAll(self. isKindOf (CoreA))”. 4 DISCUSSION The developed framework of building family structure presents several cost- and timesaving benefits. Firstly, it can help to reduce building design time and improve design quality through re-use of design modules. With development of industrialized building and prefabrication, this allows benefits of prefabrication such as higher quality and shorter construction cycles to be realized with better economies of scale. The ability to re-use and improve modules within the building family in the design function serves to enable sharing of the knowledge about product variety and commonality, not only

Development of product family structure for high-rise residential buildings

937

between different designers but also to developers and building users. By representing these structures design data, members of the design team can make more informed decisions regarding the design variety and define which structures that should be re-used across building projects which can help to sustain productivity improvements. Furthermore, the ability to represent variety information facilitates automation of tasks such as determining bills of material/bills of quantities for different variants of the building as well as simplifying plan checking on a family level of building design, which can further shorten the design time and improve estimation accuracy. This can also help designers to generate better design alternatives which can bring savings in material usage, and improve sales by quickly adapting the design to changing market requirements.

Figure 8. Use cases of implemented building family structure design system.

Ework and ebusiness in architecture, engineering and construction

938

To implement the framework, a set of proposed use cases for an implemented system for the building family structure is given in Figure 8. These use cases could be implemented as an integrated extension to CAD environments using its Application Programming Interfaces, for example the ObjectARX™ for AutoCAD® series (Kramer 2000). The object instance of the building product family can be used to generate a complete representation of the building, which can be viewed as a single IFC representation if fully integrated. This final specification is then to be used in the downstream construction process. To facilitate information sharing, IFC models can be managed using IFC model servers or other means for repository functionality. IFC models can be edited using building CAD tools or other design software. To facilitate systematic consideration of customer needs in the product family, a framework which represents ftmctional requirement of a building should be mapped to the building product family as constraints to indicate how customer requirements are translated to a modular building structure. Although the full implementation of the software has not been completed, we expect additional benefits to be realized through further development and refinement of the design framework and incorporation of more industrial design knowledge into the building family model. ACKNOWLEDGEMENTS This research is jointly funded by the Innovation Technology Commission Project UIM/119 of the Hong Kong SAR Government and Tecton Ltd., a subsidiary of P.K. Ng & Associates, Hong Kong. The authors are grateful for the support of Calvin Wong and Elvis Li of Tecton Ltd. In addition, the authors wish to thank the members of the Advanced Manufacturing Institute at HKUST for their feedback, particularly Pow Wa Siu. REFERENCES Du X., Jiao, J., Tseng, M.T. 2000. Architecture of Product Family for Mass Customization, Management of Innovation and Technology. ICMIT 2000. Proceedings of the 2000 IEEE International Conference, 12–15 Nov. 2000 1:437–443 Du, X., Jiao, J., Tseng, M. 2001. Architecture of Product Family for Mass Customization, Concurrent Engineering: Research and Application, 9(4):309–325 Du, X., Jiao, J., Tseng, M.M. 2002. Graph Grammar Based Product Family Modeling, Concurrent Engineering: Research and Application, 10(2):113–128 Filos, E. 2000. Moving construction towards the digital economy. In Gonçalves, R., SteigerGarção, A., Scherer, R., Proceedings of the Third European Conference on Product and Process Modelling in the Building and Related Industries, Lisbon, Portugal, 25–27 September 2000 Filos, E. 2002., European collaborative R&D project related to the “Smart organization”. A first evaluation of activities and implications for construction. In Turk, Z., Raimar, S. (ed.), eWork and eBusiness in Architecture, Engineering and Construction; Proceedings of European

Development of product family structure for high-rise residential buildings

939

Conference of Product and Process Modelling in the Building and Related Industries in Portoroz, Slovenia, 9–11 September 2002. Lisse: Balkema, pp. 27–32 Eisele, J., Kloft, Ellen (ed). 2002. High-Rise Manual—Typology and Design, Construction and Technology, Basel: Birkhauser Fruchter, R. 2002. Metaphors for knowledge capture, sharing and reuse. In Turk, Z., Raimar, S. (ed.), eWork and eBusiness in Architecture, Engineering and Construction; Proceedings of European Conference of Product and Process Modelling in the Building and Related Industries in Portorož, Slovenia, 9–11 September 2002. Lisse: Balkema pp. 17–26 Hop, F.U. 1988. Modular House Design—The Key to Complete Construction Efficiency, New Jersey: Prentice Hall Jiao, J., Tseng, M, Duffy, VG., Lin, F. 1998. Product Family Modeling for Mass Customization, Computers and Industrial Engineering, 35 (3–4): 495–498 Kramer, B. 2000. ObjectARX™ Primer, New York: Autodesk Press Liebich, T., Wix, I, Forester, J., Speeding-up the building plan approval—the Singapore e-plan checking project offers automatic plan checking based on IFC. In Turk, Z., Raimar, S. (ed.), eWork and eBusiness in Architecture, Engineering and Construction; Proceedings of European Conference of Product and Process Modelling in the Building and Related Industries in Portoroz, Slovenia, 9–11 September 2002. Lisse: Balkema pp. 467–471 Meyer MH, Tertzakian R, Utterback J.M. 1997. Metrics for managing research and development in the context of the product family, Management Science. 43(1):88–111 Rumbaugh, I, Jacobson, L, Booch, G.1999. The Unified Modeling Language Reference Manual. Massachussets: Addison-Wesley Santos, I.A., Hernandez-Rodriguez, Bravo-Aranda, G., A normative product model for integrated conformance checking of design standards in the building industry. In Turk, Z., Raimar, S. (ed.), eWork and eBusiness in Architecture, Engineering and Construction; Proceedings of European Conference of Product and Process Modelling in the Building and Related Industries in PortoroS, Slovenia, 9–11 September 2002. Lisse: Balkema pp. 473–480 Sarja, A. (ed.). 1998. Open and Industrialized Building, London: E & FN Spon Simpson, T.W., Jonathan R.A. M., Mistree, F. 2001. Product Platform Design: method and application. In Research in Engineering Design, London: Springer-Verlag 13(1):2–22 Suh, N.P.2001. Axiomatic Design—Advances and Applications, New York: Oxford University Press Ulrich, K.T., Eppinger, S.2004. Product Design and Development—Third Edition, New York: McGrawHill-Irwin Warmer, J.B., Kleppe, A.G.1999. The Object Constraint Language—Precise Modeling with UML, Massachusetts: Addison Wesley Longman Inc. Warsawski, A.1999. Industrialized building systems, London: E & FN Spon Wix, J. & Liebich, T. 2001. Industry Foundation Classes Ifc 2x. http://www.iaiev.de/spezifikation/IFC2x/index.htm. Wong, Chi Kuen Calvin (proprietor). Patent Publication Number: 1021475. International Patent Classification: B04B, B04H

Construction site and project management

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Assistance to building construction coordination by images Kubicki Sylvain, Halin Gilles & Bignon Jean-Claude MAP-CRAI, (Research Centre in Architecture and Engineering, Nancy, France) ABSTRACT: This communication describes a research theme about new tools to assist architectural design and building construction focus on the use of imagery. The article focuses on specificities of architectural design and building construction stage as collaborative activities. We suggest here two different potentialities of building site imagery. The first consists in a use to assist coordination between actors during construction stage, while the other one describes specificities of a knowledge management tool (pathology prevention assisted by images). We present finally the prototype set up to illustrate meeting reports and diffuse information to the operation’s actors.

1 INTRODUCTION Nowadays, many changes have happened in the AEC sector concerning concurrent engineering work methods. Many studies attempt to characterize specificities of prqject and design in architecture, in order to introduce new tools. This article is part of the concurrent engineering research works of CRAI (Nancy School of Architecture). We present here a research theme, which is an extension of works on tools propositions for architectural design concurrent activity. These works also studied the role of images in architectural design. Our communication focuses on the use of building construction digital imagery. We will describe the specificities of architectural design activity and particularly the differences between “initial and technical design” in architecture and the building construction stage. These first statements will allow us to describe how the image can assist these activities in which many actors are involved. We will suggest a method to build and use a building construction image base, describing relevant information needs. We will talk about image collection problems (sources, index methods) and about possible uses of these images in coordination (or communication) and in knowledge management. We will present in the next part the experiment being developed at the moment, which will illustrate the meeting reports. Our goal is to use the images as a communication tool (around the meeting report) and to manage technical information thinking of future uses (building site image based system to prevent construction anomalies). Finally, we will talk about recent evolutions and conclude on these works.

Ework and ebusiness in architecture, engineering and construction

942

2 ARCHITECTURAL DESIGN AND BUILDING CONSTRUCTION ACTIVITIES The architectural design is the object of many works aiming at appreciating its specificities as design activity [Simon 1990, Al Hassan 2002]. Building works construction develops specific problems too that we will attempt to characterise here. Our general research goal is to suggest new tools to assist these activities. We are particularly interested in collaboration around design and construction stages. We will now describe particularities of these two activities of the architectural project and used tools. 2.1 Architectural and technical design stage Architectural design is the place where a creative activity encounters an engineering activity (technical or user constraints). Design is generally supervised by the architect, first project designer, commissioned by the client. The architect surrounds himself with other specialist actors to resolve and anticipate project aspects that he can’t master such as technical design (structure, fluids…). Architectural design activity consists of a mechanism of proposition-validation of solutions between actors, in order to find a satisfying solution to the building project. Exchange documents are principally plans, technical notes or schemes. This stage can be assisted by specific “profession tools” (e.g. CAD tool for architects). Groupware tools can assist collaboration between designer teams. These tools allow users to group documents or to manage the tasks of each participant During the first stage of the project, actor coordination is very often implicit because there are not many actors and those who exist know each other well. Work mode is coupled and actors work principally in a synchronous way. 2.2 Building construction stage This first stage of the project described above in is followed by the building contractors consultation. Then comes the building construction stage. During this stage, the three actor groups described before stay stable. The client role is resumed in a building work progress validation task. The design team often engaged a coordinator, responsible for task realisation progress. The work group expands and includes every building contractor. Actor relations become more hierarchical and distant because of the aim of respecting deadlines and costs. Work and data exchange is made sequentially and actor meetings are based on validation of an asynchronous work. The principal tool for assisting this stage is the “building construction meeting report”, great link and communication tool between actors. It contains textual information and progress charts which help everybody in task realisation comprehension. There are not many computer-based tools employed to assist this stage in the AEC domain. But we think that the sequential character of activity during building construction is propitious for the integration of workflow tools (task management, materials supply…). This work mode is the result of a gap existing between different actors: there is no durable link between them. This is due to the re-composition of teams at each project and

Assistance to building construction coordination by images

943

to the coordination mode based on contracts. This characteristic penalizes the group because actors use specific tools! 2.3 Design assistance tools Characteristics of architectural project collaborative activity described here have been analysed in works developed in the MAP-CRAI [Malcurat 2001, Hanser 2003]. A model representing the variety of these exchanges has been proposed following a logic guided by the “representation of relations between actors, activities and documents during the project” [Hanser 2003]. More other, we are at present seeing the development of quality charts: designers and architecture studios need methods and tools to assist them… In this context, reflexions about new tools are based on two principles: – Architectural design assistance to increase project quality, – Assistance to the collaborative work between design/ construction teams based on appropriate tools (communication and project management quality). In part IV, our propositions are developed on these two basic principles. 3 THE IMAGE The image is, nowadays, a support largely used to carry information. The reasons for the efficiency of the image are well known and numerous. We are particularly interested in the following characteristics: – Considerable physiological sensibility of the person whose perception is predominated by visual images, – Great aptitude to memorization of images, – Great capacity of image encoding, – Instant global message, – Proof effect, – Iconic seduction. [Bignon 2002] 3.1 The image in architectural design Image plays an important role in architectural design mechanisms. It’s both the first material of creation and a tool to comprehend a problem. It’s also the principal media used to transmit architectural doctrines. This visual culture of architects leads them to develop a specific meaning called “visuo-spatial” [Gardner 1992]. In this specific work practice, meaning mechanisms are very often built by image. Research works have been developed in MAPCRAI around this theme. Their objective is to study the possible uses if images to access information during the architectural design process: from idea emergence to project realisation.

Ework and ebusiness in architecture, engineering and construction

944

According to the moments of design, the image can play different roles. We are interested here in two major functions: the image as reference (in the early stage of design) and the analogous image (the designer will search for and identify possible solutions by making correspondence between the image of an object or a work and the imagined solution to a project.) [Halin et al. 2003]. A study of the use of image as information search support has been developed to access building product information [Nakapan 2003]. The information search by image uses image search for “user needs” formulation. The user formulates his request by choosing or rejecting images. This request is analysed to permit products selection. This process needs to use a common ontology for image index and product index. We introduce here a particular work issue based around building construction images. 3.2 Building construction images benefits The particularity of building construction image is that it shows an object being fabricated. We must distinguish between two different uses: Image illustrates the building construction’s general progress, or particular “works under construction”. (Note: We called “work under construction” a basic part of the building being built). In this case, image plays aproof role. Image can transmit information contained or be a tool to access other related information (illustrated by images). It therefore enables the user to capitalise on knowledge of the terrain. 3.2.1 Works realisation proof Generally, the photo taken of the building construction site at a precise moment is a building construction progress statement. Image is proof of this progress and can be used in different cases (actor communication, archiving…). We introduce here a relation between particularities of images taken on building site and the “building construction meeting report”. This document is the basis of the coordination in the building construction stage. A brief analyse of its content permits us to find the same notions: particular work progress statement, building work or actor interface details. Nowadays photos sometimes illustrate meeting reports. Architects largely accept the role of image to increase communication quality but not everyone agrees on its regular use in the meeting report. There is some opposition to these propositions, such as some architect wish to produce short meeting reports. We characterise this particular use of building construction images as a vector enabling a project realisation context. We can note too that a particular objective of the setting up of quality charts is the necessity for each actor to globally understand the context of its intervention. Taking into account this environment (global work progress, actor interfaces) lead to the auto coordination of actors. Now we will see how these building construction images can serve knowledge management tools.

Assistance to building construction coordination by images

945

3.2.2 Capitalisation of a terrain knowledge An image base built and used in the building construction stage must be completed by semantic information. Every future use is conditioned by the development of an index ontology (based on coordination). We suggest two different levels: knowledge comprehension assistance (e.g. image as representation of a specific problem) and image as a guide to link the user to other information. Using the image to represent a phenomenon or an object is not innovative. We would say here that such practices are current among architects, who take photos of their realisation or building site. Their goal is to capitalise knowledge and skill. The use of an index method will allow future search in the image base (e.g. precise operation or particular work image search). Based on these propositions, we suggest using image in order to formulate a request, and so assisting the designer when he is not able to formulate a design problem (vague need) for himself. The interest of search by image in architectural design activity and particularly of assisting a vague problem formulation has been developed in a PhD work [Nakapan 2003]. The request formulation assisted by image could guide the user to other information (the content of this information is to define in relation to image specificities). 4 PROPOSITION OF A METHOD AROUND THE MEETING REPORT A tool has been developed to experiment the use of image in a construction operation. 4.1 Objectives We have set up a tool allowing users to illustrate the meeting report by images of the construction operation. A study of the meeting report general structure has been developed in order to define exactly the experimental context. We have made fundamental hypotheses. Independently of the form of the document, we can target in its structure two types of information that interest us directly: the progress notion and the particular points. General construction progress relates to tasks or particular work realisation. Particular points refer to details or comments about a specific work. The model presented (Fig. 2) explains the constitution of the document and the different parts that comprise it. Our proposition consists of illustrating the information of “progress points” and “particular points”. The textual information illustrated by the image becomes our index source. The content of the text is linked to the concepts of task (activity), actor and document (a point concerning a specific document, e.g. plan). The specificity of the AEC domain implies the notion of “built work” which is present in all information on the meeting report. Figure 1 is a general scheme of the method developed. It represents the two different spaces of image uses: coordination and capitalisation.

Ework and ebusiness in architecture, engineering and construction

946

Figure 1. Experiment principle. Figure 2 presents the conceptual data model of the meeting report document. We will describe the prototype developed based on this model.

Assistance to building construction coordination by images

947

4.2 Experiment description through model description First, the model represents the structure generally observed of the meeting report document: actors presence table, general observations, particular points and progress points (or table). We suggest illustrating particular and progress points with an image that will be indexed in relation to the point content. The implementation of this model in a database has allowed the development of a meeting report tool interface. At present, the index stage is “manual”, the user must choose index terms in two categories: “build work” and “actor”. In the future, we envisage text analysis functions to allow a direct concept extraction from the meeting report text. In the context of this experiment we are doing the data capture but we are developing too a user-friendly interface in order to define a meeting report assistance tool for building construction coordinators. 4.3 Scenarios of use by building construction actors We have set up a web server to diffuse our parallel meeting report to each participant. Users can consult the basis of the meeting reports related to their intervention. For each point in the meeting report, an image can be visualised (small view or big image download). A contextual menu on the image sends users to other images by “proximity criteria” that we will now describe: – “Work under construction” statement proximity. The tool suggests displaying images of the same building work on previous progress states (e.g. week before). – The geographical proximity of built work. With such a function, the user can identify other works in the same area at a specific time (e.g. before, at the same time or coming later). For example it allows the identification of interfaces between actors and risks. – Actor’s proximity. Who works in the same area? What building works are concerned? etc. We think that such information will develop the consciousness of a common work and increase communication between actors. Our hypothesis is that these dynamic navigation functions will allow the user to obtain contextual information about the building project and better situate his own intervention. In our experiment, this function of “proximity” search around images will allow us to better evaluate the potential of images such as a project context visualisation help tool. How can image serve building progress while allowing or increasing the actors auto coordination? Figure 3 shows a view of the web user interface developed (the visualisation of a meeting report). 4.4 First assessment The research work presented here has been approached in different ways. An investigation among architects has allowed us to analyse their needs and their attempts concerning new tools.

Ework and ebusiness in architecture, engineering and construction

948

This investigation has shown a real interest in the use of photography, and everybody agrees with its technical character. On the other hand, we have noted the existing needs and the interest in new computerbased tools to assist design and realisation teams. The tool developed is in an initial statement (prototype). At the present it only allows users to manage “particular points” and “progress points” in the meeting report. In the present version, the user can only insert one image and we notice that it’s too limited in some cases. In fact, for some details two photos could increase the comprehension: a large view of the building work and a “closed” view of the detail.

Figure 2. Meeting report data model.

Assistance to building construction coordination by images

949

Figure 3. Web user interface. Concerning the “web user”, the interface is in its first version. We simply display information of a point as a table containing a text, a photo and other information (geographical area and progress) (Fig. 3). We note some limits of the interface. First in the comprehension of areas: a classification by areas would be clearer. Secondly, we envisage graphically signaling the progress statement of a building work, particularly to show the works behind schedule… Finally, we will develop the “proximity links” described above in to increase the dynamic use of the tool. 5 RESEARCH PERSPECTIVES Focusing on coordination around the meeting report we can imagine other methods. The image could be set in relation to a theoretical progress statement (such as a Gantt diagram or digital mock-up) in order to show possible problems in construction progress.

Ework and ebusiness in architecture, engineering and construction

950

Beyond this proposition of an everyday use of the photo, we immediately notice the bringing-in of this media into the building life cycle. Many ways of thinking are open too in the patrimony management. For example, illustration of building work sequences enables us to keep a trace of what has been made and how it was made… Thus, “building works” construction information can be reused later, particularly when building works are hidden by other works in the final state of the building (e.g. pipes passages). We underlined too the interest in image in knowledge management. We are at present setting up the structure of a construction risks prevention tool (called here “pathology prevention”). The “search by image” described in part 3.1 seems to be adapted here to allow the user to access information. The designer could navigate without a precise request and be informed about possible pathologies (function of materials used, build works or actors). Technically the search engine could answer the requests (formulated by the image) making the link between two ontologies: one indexing image and the other one indexing a pathology case. 6 CONCLUSIONS Introductive parts of this article show that the study described here follows other research works which allow us to characterise cooperative activity of “design and realisation stages” in the architectural project [Halin, Hanser]. These studies allowed us too to demonstrate the major role of image in architectural design activity as an information vector adapted to the architect cognitive reasoning. [Bignon et al.]. This article presents a research work focused on construction coordination and knowledge management. Our propositions are based on the building construction image or photography as information vector and navigation tool. We want to demonstrate here the place of image as an accessibility vector to a particular work environment: the building construction. The sequential tasks of building construction, precisely described in many documents (progress charts…) are important characteristics to give sense to images. This temporal aspect is very important for every future use. The information content in the meeting report “particular points” is very interesting too because it introduces the particularity linked to the works building stage: e.g. pathology, risks and defects. The proposed functionalities of assistance tools follow these two particular properties of images: general progress and particular points. A first proposition consists of tools oriented “building construction coordination” (workflow), and a second type of tool focuses on assisting designers during the initial design stage bringing terrain knowledge (e.g. pathology risks information). The prototype developed is at present tested on two building sites and will allow us to verify hypotheses described in this article concerning the assistance to the actor coordination by image. A parallel functionality will be developed and available for users concerning the pathology information tool (described in part V).

Assistance to building construction coordination by images

951

REFERENCES [Abeid 2003] ABEID (Jorge), ALLOUCHE (Erez), ARDITI (David), HAYMAN (Michael).— Photo-Net II: a computer-based monitoring system applied to project management.—in “Automation in Construction” 12 (2003) 603–616.—Elsevier Ed.—2003. [Al Hassan 2002] AL HASSAN (E), TRUM (H.) and RUTTEN (P.)—Strategic Briefing. A Conceptual Process Model for Building Design.—In proceedings of DDSS’O2, 6th Conference, Ellecom, Netherlands, pp: 168–185.—2002. [Bignon 2002] BIGNON (J.C.)—Modelisation, simulation et assistance a la conceptionconstruction en Architecture—Habilitation a diriger les recherches, Nancy—2002. [Gardner 1992] GARDNER (H.)—Multiple Intelligence: The Theory in Practice.—New York, Basic Books. Ed.—1992. [Grezes 1994] GREZES (Denis), HENRY (Eric), MIC-QUIAUX (Dominique), FORGUE (Michel).—Le compte rendu de chantier, rapport final de recherche.—Plan Construction Architecture, 1994. [Halin et al. 2003] HALIN (G.), BIGNON (Jean-Claude), SCALETSKY (Celso), NAKAPAN (Walaiporn) and KACHER (Sabrina)—Three approaches of the use of image to assist architectural design.—In proceedings of CAADRIA 2003 (Computer Aided Architectural Design Research In Asia), Bangkok, Thailande.—2003. [Hanser 2002] HANSER (Damien), HALIN (Gilles), BIGNON (Jean-Claude).—Toward a user adaptive vision of architectural projects. Conference eCAADe, Education in Computer Aided Architecture and Design, p.238–245,—Varsovie—septembre 2002. [McCready 1992] McCready (S.)—There is more than one kind of workflow software.— Computerworld,—November 1992. [Simon 1990] SIMON (H.A.)—Sciences des systemes, Sciences de 1’artificiel.—Paris, Editions Dunod—1990.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Gesprecons: eSafety and risk prevention in the construction sector J.M.Molina, M.Martínez & I.García AIDICO, Volencia, Spain ABSTRACT: This paper presents the results of Gesprecons: a platform for collaborative work on safety and risk prevention in the construction sector. Gesprecons system provides support in the generation and application of the Health and Safety Plan. It provides the integration of on-site availability of the documents, activity plans, test data, inspections and results, that may have any relation with safety assurance in building and construction companies. For that, pre-structured context-focused quantity and quality test data, simple access to technical knowledge (standards, codes for practice, text books, co-operate company knowledge, contract specification and of course agreed alterations kept in multi-media notes, etc.) have to be provided in order to enable comparison according to best practice and state-of-the-art.

1 INTRODUCTION The high rate of misfortune accidents within the workplace is one of the main challenges faced by the construction sector. This is caused by three fundamental elements: The need of specific organisation activity, the lack of information related to industrial health and safety received by contractors and other employees responsible for safety procedures, as well as related legislation regarding to risk prevention and finally the simultaneity of different activities with numerous companies at every stage of work. This situation joined to the intermittent participation of all the agents involved in each construction site creates a very complex situation to guarantee that labour risks information at every specific phase of the work site is enforced by the safety coordinator. On the other hand, in nowadays competitive industry, it is a matter of fact that differentiation can give the companies the key to get the leadership. Safety assurance in the working environment in the construction industry is an issue that can help the companies to get that differentiation. Safety on construction sites demands the close interaction of the construction-site players and public authorities, laboratories and project surveyors. Codes, standards, regulations as well as guidelines have to be quickly at hand, interpreted and understood in a common sense in order to ensure safety continuously. The right decision taken at the right moment can avoid serious accidents thus preventing from damages and even deaths. Gesprecons defines a cooperation model among the different work construction representatives from the safety perspective: facultative guidelines, safety coordinator during building phase, constructors, sub-contractors, personnel delegates, personnel

Gesprecons: eSafety and risk prevention in the construction sector

953

designated by the companies in security matters (according to the prevention law), and the employees. This approach provides personnel dedicated to the control of health and safety and risk prevention at the construction site with a tool that allows decreasing the number of labour accidents existing within this sector. Therefore, it could guarantee the application and fulfilment of the current safety normative by the personnel in charge of assuring the achievement of the Health and Safety Plans (HASP). In order to reach each subcontractor and agents involved in the work construction, the model is based on the use of mobile and static Internet technology, as well as communication through SMS to facilitate contact with autonomous personnel. The system transmits information regarding labour risk prevention and safety alerts detected by the integration of data capture sensors in the construction site. In a higher level, the system is able to react to possible consults that the user might encompass at the workplace. This is accomplished by linking the consults to a Safety Plan database and a risk prevention database specific for building work activities. In order to provide the different stakeholders with the updated information at every moment, a huge effort has been done in the part of the documentation for the information systems for Gesprecons. The information has been structured in two categories: construction labour and risk prevention. In both cases, current way of working, documentation, bibliography and experienced people have been consulted in order to provide the final users with the most useful information and as well structured as possible. 2 OBJECTIVES The main objective in the development of Gesprecons platform is to offer a remotely accessible collaborative tool for the creation and subsequent application of the HASP. This main target can be detailed in the items described below. – In a general point of view it aims at decreasing the current high level of misfortune accidents between the workers within the construction site thus decreasing the level of deaths and serious injuries. – It intends to promote the Health and Safety law fulfilment in two aspects: the creation of HASPs and its correct execution. This is done by means of facilitating the knowledge of the contents of the law. Currently the preparation of most HASPs consists of copying a previous project and slightly adapting it to the new environment. Later on, the application of the preventive measures imposed by this HASP is very low and difficult to control. Gesprecons facilitates the creation of the plans and supports the responsible agents for its application. – As a positive side effect, the use of Gesprecons increases the construction companies competitiveness. Most of them are SMEs, thus having difficult access to the research on new technologies. Gesprecons facilitates them the advantages provided by technology. – One major issue is the exoneration from responsibilities. This is a very important point, because the responsible agent for the application of the risk prevention measures (Safety Coordinator) has to demonstrate his part of the work in case of accidents. Gesprecons, by keeping register of all the transactions, contributions, warnings, alerts,

Ework and ebusiness in architecture, engineering and construction

954

etc. will provide a legal framework to demonstrate his part of the work was accomplished. – In a naturally collaborative environment as the construction sites, where a rather high number of different companies have to share their work space in a short period of time, it is very important to ease the coordination amongst the different stakeholders. This is usually called eColaborative work and Gesprecons provides the framework for it. – In line with the previous point, it is also an important issue to ease the communication flow amongst all the participants at the construction site. Gesprecons provides a common panel to exchange information, either related to HASP or to any other matter in the construction site. – The general Labour Risk Coordinator usually works in several construction sites at a time. This tool provides him with a tool to concentrate the management of all the different construction sites he is working on in one only location. – Gesprecons intends to provide a tool to establish and control work flows in the building work amongst the participating stakeholders. Thus allowing to define the flow of documents, alerts, hierarchical relations, etc. – One major concern is to get an application likely to use. It is a difficult environment and the barriers to apply new technologies are very high, as the working people are not very well prepared. In order to get people using it the application must be very friendly and provide real help in the daily work. – Promote the eWork in the construction industry. It is an industry naturally distributed, each company is working in several sites at a moment. Thus it is an ideal scenario for the application of eWork. Gesprecons platform will extend the office to the construction site, giving seamless connection to the workers. – Furthermore, and apart from all the previous objectives, Gesprecons is only the first step towards the development of a platform for the collaborative work in the whole life cycle of building. Thus including work plan scheduling, quality control, risk prevention control, eProcurement, facility management, etc.

3 METHODOLOGY In order to reach the ambitious objectives stated in the previous section, the application has been carefully designed and developed according to the following steps: – Information compilation. Firstly a hard task of research in the building problem was performed. This research was mainly focused on the Health and Security field. – Process modelling. Then the processes included in the application were modelled using standard representation languages. – Data modelling. Thirdly a data model was deployed to cover the information needs within the problem. – Web tool development. Finally, the tool was developed as a web tool. In the following subsections these four steps are described giving more detail of the actual procedures of development.

Gesprecons: eSafety and risk prevention in the construction sector

955

3.1 Information compilation The information compilation task is a major issue within this kind of project. The group needed to

Figure 1. Gesprecons data model. gather all the key information. For the final outcome to be an useful tool it must improve and ease the current way of working and at the same time take into account all the legal compulsory issues. In order to reach these objectives, it is crucial to have all the relevant information. In the project this information has been acquired from all the different involved sources: Firstly all the legal information [1,2,3], including normative, laws, procedures, have been analysed; then the main current software applications used in the sector with similar aims have been tested; also the most updated bibliography related to Health and Safety has been consulted [4,5,6,7] and finally and probably the most important, the potential users have been contacted and questioned about their expectations of such a system. The Spanish Law Ley 31/1995 for Labour Risk Prevention, which transposes the European Framework Directive 89/391/CEE, established the obligation for the constructor: To plan the preventive action from an initial risks evaluation, and to evaluate

Ework and ebusiness in architecture, engineering and construction

956

the risks inherent in the selected work tools, substances, and work places conditioning. This obligation has been developed in the chapter II, articles 3 to 7 of the Real Decreto 39/1997, Regulations for the Prevention Services. 3.2 Process and data modelling In order to develop an application that covers the Risk Prevention Tasks the actual processes have been modelled. To this end, all the compiled information has been analysed. Special attention has been paid to the comments from the potential users. This being so because they provide the real taste of the current processes. By analysing the information managed within the processes, a data model has been defined. This data model consists of the data structures needed to perform all the operations in the Risk Prevention. It is shown in Figure 1. 3.3 Web tool development The platform has been developed in the form of a web accessible application. The objective was to maximize the accessibility to the application. By developing a web application the users will access through any device equipped with an Internet browser. Furthermore, updates in the application will not affect the users, as it needs not be reinstalled in their PCs, thus producing a dynamic system. The application development has been done following the criteria of technology independence and cost minimization, always keeping the level of performance. This way, the programming has been done with JAVA, the database system is MS SQL Server, and the applications server is Apache Tomcat which allows for encrypted connections through https. One important issue to be commented is the use of web services in the development of the alerts service. In order to provide independence between the communication module and the rest of the application, they have been implemented as separated parts which communicate through web services. This way changes in mobile technology (as the very close use of UMTS) will not affect the application validity. 4 DEVELOPMENTS In this section the main functionalities offered by the application are described. It is important to highlight that one of the main issues taken into account has been the usability. For this reason the design of the user interface has been specially studied. The main criteria for the design have been: – To offer access to most important functionalities in every screen. – To reduce the number of steps to reach a determined function. – To show the user the path he has followed to reach a function. – To make the functionalities easy to use. – Allow different profiles.

Gesprecons: eSafety and risk prevention in the construction sector

957

The development of the platform has comprised two main parts: The database generation and the application implementation. In the following subsections these developments are detailed. 4.1 Information database As previously introduced, there has been a hard work in the side of the database contents preparation. Not only in the selection of that information, but also in its structuring. The information is divided into two types: construction labour, and construction risks. The former is composed of the elements that describe a construction process: phase, activity, materials, machinery, and tools. The latter is composed of the concepts related to safety issues: risk, prevention measure. Of course both types of information are interrelated, in fact any of the construction elements may have several risks and each risk several preventive measures.

Figure 2. Information system structure. Table 1. Database figures. Concept Phase

Number

Relations 16

20 activities

250

7 materials 8 machinery 45 risks

Machinery

74

12 risks

Materials

36

7 risks

130

14 measures

1200

–

Activity

Risk Measure

Ework and ebusiness in architecture, engineering and construction

958

Figure 2 shows the structure of the information database. The concept is that a construction work is divided into phases. Each phase consists of a set of activities. In each activity a set of materials and machinery are used. All of the construction elements (phase, activity, materials,…) can trigger a set of risks. And finally a set of preventive measures must be applied in order to remove or at least reduce the risk. All the information related to construction labour and risk management has been studied and fitted into the scheme shown above. The database is accessible and the system administrator can easily do changes, such as adding new items, deleting others or modifying the existing ones. So, once this structuring was agreed, the next step was to organise all the compiled information according to it. Table 1 shows some representative figures about the database. This shows the huge amount of work dedicated to the information system in the application. The first column of the Table 1 shows the different types of elements contained in the database. The second column shows the number of elements contained in the database for each type. And finally, the third column shows the average of relations that each element has with each of the other elements.

Figure 3. Gesprecons login screen.

Gesprecons: eSafety and risk prevention in the construction sector

959

4.2 Application The main objective of the application is to offer support to a user in the generation of the HASP for a construction site. Furthermore, the aim is to allow for the collaborative participation of several users in the creation and later treatment of the HASP. Figure 3 shows the login screen for the application. Depending on the user identification the application addresses the user to a different interface, one is addressed to the system administrator, and another one to the normal user. By means of the first view, the system administrator can maintain the system. This includes two main operations: Administrative management, the administrator can sign up, delete or modify the data of the user companies; and information database maintenance, here the administrator can update the contents of the database including new elements or modifying the current ones. The second view is the user interface and provides access to the main functionalities of the system. The contents shown in the different screens depend on the user profile. The system allows for the users to access to different construction works with different profiles. This way a user can be the main safety coordinator in one construction and only a participant in the HASP creation in another one. The list of functionalities offered to the user is the following: – Make the HASP in a collaborative way. The platform main aim is to allow the preparation of the Health & Safety Plan in a collaborative way. To this end, the system allows the users to define the hierarchy they want to follow amongst the different companies participating in the preparation. – Gesprecons platform assists in the HASP execution. It can automatically send alerts notifying the affected workers of a hazardous situation at the construction site. It can send notifications about beginning or ending of phases, risks, etc. – Gesprecons allows for a coordinated management of the construction schedule. This way several companies can work in a construction in a collaborative way using the system as a communications tool. – One usual task for the H&S coordinator is to check the actual fulfilment of the preventive measures in the construction site. This task is performed by means of the preparation and fulfilment of the appropriate checklists. A checklist contains the set of conditions that each preventive measure must accomplish. Gesprecons assists in the preparation and later fulfilment of such checklists. Furthermore, it allows the user to access from the construction sites through mobile devices.

Ework and ebusiness in architecture, engineering and construction

960

Figure 4. User main page. – The web accessibility provided by Gesprecons allows user to access remotely to the system databases so disposing at every moment and place of information about regulations in Safety and Risk prevention. Both figures below show the look of the user interface. Figure 4 is the main screen that the user finds when he logs into the system. This screen provides the user with the most important information (pendant measures, recent alerts,…) and facilitates the access to the main functionalities. Figure 5 shows the graphical visualization for the HASP schedule. It is a nice tool for the user to get a fast overview of the global planning. Besides it also provides access to the screen for modifying the elements just clicking on the bar. It shows each type of element in different colour. 5 BUSINESS BENEFITS The use of the platform Gesprecons in the construction industry offers a list of benefits for all of the participant stakeholders. On the one hand it provides the implicit benefits of an eWork application, namely distributed, collaborative and remote work. On the other hand, it provides some specific benefits related to the particular sector it is aimed at. Following these benefits are explained, detailing which are the main aspects for each of the main groups of agents participating in the health and safety assurance in the construction sector.

Gesprecons: eSafety and risk prevention in the construction sector

961

Firstly for the construction companies, which must accomplish the Health and Security Law. They are the main actors in this scenario. They have the strength to force the other participants to perform a complete and detailed monitoring of the HASR The benefits that apply directly for them are: – It allows them easily generate and execute the Health and Safety Plan. – The expertise needed to prepare the plans is lower because the tool provides advice, knowledge management and reusability of previous work. – Collaboration workflow with their subcontractors can be defined. – The invested money on the application of the HASP can be reduced. One of the main benefits in this line is the automatic detection of overlapping preventive measures, thus reducing the costs.

Figure 5. Gantt diagram view. Secondly, another big benefited from the system is the Safety Coordinator, whose main advantages are stated below: – He can exonerate his responsibilities because the system keeps registry of his actions, mainly the communications and actions requests to the other participants in the construction work. – He can consult and modify the HASP at any moment and anywhere with an Internet connection. – He can easily know at every moment who is the person responsible for any activity, thus facilitating his communication tasks.

Ework and ebusiness in architecture, engineering and construction

962

Finally, the system provides high safety improvements for the workers on the construction site: – They have a safest working environment. – They have an easily accessible channel to throw an alert in case of any emergency.

6 CONCLUSIONS AND FURTHER WORK The application of these new work methods provides the involved companies with a significant improvement in their internal management, documentation, and resource management. More specifically, this tool eases the interaction amongst different agents and facilitates a common environment for health and safety management at the construction sites, thus reducing substantially labour accidents. Currently the application is at a first trial period. The initial feedback from the users has been very positive and some constructive suggestions have been reported. In the next months, after taking into account the suggestions from the test users, the platform will start its exploitation phase. Apart from the modifications suggested by the test users, there is a set of improvements already planned. These improvements are focused on the openness of the system. For instance to allow the application to import data from standard formats, to allow the calculations of budgets, etc. Another improvement will be focused on the connectivity. This way the system will be done more accessible, i.e. through advanced mobile devices. To this end the application will be configurable, and the contents will be displayed depending on the connected device. The target devices will be mainly pocket PCs and third generation advanced mobile phones. The final aim of the group is to develop a multidiscipline platform for collaborative work in the construction sector. Gesprecons is the first step. Following steps will add new functionalities to the platform, for instance to assure the Quality procedures fulfilment. Furthermore, the next steps are addressed to the improvement of the application. Indeed the work is already under development in different work lines. On the one hand to add mobility to the system in order to make it accessible from the construction site. On the other hand, to provide the system with capabilities for workers’ situation detection in order to perform selective actions depending on the presence of workers in a given area. REFERENCES [1] Ley 1627/1997, Disposiciones minimas de seguridad y salud en los lugares de trabajo. [2] RD 39/1997 de 17 de enero. Reglamento de los Servicios de Prevención. [3] Ley 31/1.995, de 8 de noviembre, de Prevención de Riesgos Laborales. [4] Manual Básico de Prevención de Riesgos Laborales. Cuadernos Cinco Días. Centros de Estudios Financieros. 1999. [5] Guia práctica para la prevención de riesgos laborales en obras de edificación. Generalitat Valenciana. Conselleria de Economia, Hacienda y Trabajo. 2003.

Gesprecons: eSafety and risk prevention in the construction sector

963

[6] Manual de Seguridad y Salud en la Construción. Pedro-Antonio Beguería Latorre. Colegio de Aparejadores y Arquitectos Técnicos de Gerona. 1998. [7] Manual de seguridad y de riesgos laborales y de la protección del medio ambiente. Mutua Universal. CIE. Dossat2000. 1999.

eWork and eBusiness in Architecture, Engineering and Construction—Dlkbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Intelligent Construction Sites (ICSs) T.Mills, Y.Jung & W.Thabet Department of Building Construction, Virginia Tech, Blacksburg, USA ABSTRACT: This paper introduces and explores the concept of Intelligent Construction Sites (ICSs) supported by current technical tools grouped within an Information Technology (IT) Toolbox. An ICS is more than intelligent site utilization; it is a concept similar to Intelligent Buildings, i.e., active electronic processes and information systems that contribute to the overall operation of the construction plant for its intended purposes. ICSs are designated construction sites that use advanced IT tools to the maximum extent possible. Informational intelligence that contributes to the identification of an ICS is categorized into four broad domains: Digital Imagery Processing, Electronic Data Interchange, Process Modeling and Visualization, and Virtual Collaboration. Tools that support these domains are identified and their contributions within these domains for supporting construction operations are addressed. The nature and extent of these domains is discussed and the associated digital tools that make up an ICS toolbox are profiled. An example that maps Intelligent Tool utilization among the four domains of intelligence and each tool’s contribution toward optimizing a solution to a specific field problem is initiated. The paper concludes by identifying ICS transfer mechanisms and challenges that can be encountered as efforts are made to determine a site intelligence quotient (IQ) or site IQ.

1 INTRODUCTION The lack of accurate, reliable, and timely information exchanges between parties, due to industry fragmentation has historically created inefficiencies, cost overruns, and interparty disputes that too often characterize the construction process. The perceived fact that many actors in the construction process consider each project a customized one-off activity, designed and built by different parties who then go their separate ways, reaffirms the opportunity and need for standardized and repeatable procedures for information exchange. Latham (1994) and Egan (1998) both express industry beliefs that information technology (IT) should have a positive influence on direct field performance. The owner communicates to the designer, who in turn communicates to the constructor, who then communicates instructions to field trades, workers and suppliers. The work that is produced is then inspected and results are relayed back to the constructor who may then be required to affect any corrective work. The dynamic nature of this information exchange frequently results in the inability to predict necessary actions. The resultant inactions that may occur reduce on-site performance. The outcome

Intelligent construction sites (Icss)

965

of this fragmentation on overall on-site performance is manifested in problematic and productivity reducing activities such as untimely changes, non-productive labor tasks due to wrong or absent information, disputed change orders, accidents, double handling of material, incorrect material availability, and so on. Of all these problem areas, changes have the most profound effect on altering performance. In addition, many parties can initiate a change in the process, and therefore, it is essential to incorporate uniquely intelligent IT tools to affect a positive outcome on performance, particularly from a productivity position. Egan’s 2002 follow up report “Accelerating Change” recognizes that IT and the Internet are important enablers toward this end (Sun and Howard 2004). For purposes of this discussion, the term “performance” follows Oglesby (1989) definition as encompassing productivity, safety, timeliness, and quality. Changes are a standard part of the building process and are based on informational exchanges and accurate and timely communication among the engaged parties, but they cannot be predicted. Although the construction industry is increasingly adopting IT tools to improve performance, construction is still struggling with inefficiencies and reduced productivity due to ineffective information exchanges. In an effort to utilize IT to improve performance, it becomes necessary to identify and define an IT toolbox that can be developed and used to improve on-site performance. The objective of this paper is to identify and investigate existing information technology tools, categorize them within specified domains and demonstrate how they may be integrated and utilized as on-site problem solvers, thus creating an intelligent construction site (ICS). By identifying the intelligent tools and their transfer mechanisms, an ICS can be defined and designated intelligent. The concept of a site intelligence quotient (IQ) or site IQ is also presented. 2 INFORMATION TECHNOLOGY (IT) IN CONSTRUCTION IT is a term that encompasses all forms of information technology and is commonly understood as software applications, computer enhanced operational methods and techniques used to create, store, exchange, use and archive information in its various forms including data, voice, images, multimedia content, and other informational forms, including those not yet conceived. In the latter 1990’s the Internet has been intensively explored as a 24/7 platform that allows push/pull information exchanges between architects, engineers, construction managers, and construction companies regardless of site location. These project specific websites (PSW) or automated communication sites are only one of many IT tools (Unger 2002, Dawood 2002). There are many other IT tools used to simplify and solve some of the complexities of informational exchange within construction. Sun and Howard (2004) have compiled an extensive inventory of IT strategies and tools, all revolving around shared project databases, which are available to the construction industry as enterprise process enhancers. Among the on-site tools referenced are: 3D representations, bar coding for material handling, laser positioning system for field measurements, videoconferencing, mobile computing processes, etc. With the advent of virtual sites, the limitation of tools for use at a specific location, office or field, is being mitigated. What once may have been an office

Ework and ebusiness in architecture, engineering and construction

966

function can now often be handled from a remote location. IT has reduced the time/distance dimension and resulted in opportunities for ICS. 3 INTELLIGENT CONSTRUCTION SITES (ICSs) Traditionally an “intelligent building” is defined by the latest software applications and IT hardware within telecommunications, electronics, security, automation, and building energy control systems (Stein and Reynolds 2000). Similar to an “intelligent building,” an ICS is a designated project site, Figure 1, which

Figure 1. Intelligent Construction Site (ICS) diagram. Table 1. ICS tool domains. Digital Imagery Processing

Electronic Data Interchange (EDI)

• Dynamic Scheduling • Decision Support System

• Electronic Forms • Electronic Inventory • Positioning Systems

Intelligent construction sites (Icss)

Process Modeling and Visualization

967

Virtual Collaboration • Web-based project management

• 3D Visualization • Interactive virtual walk-throughs and virtual construction

• Electronic document management • Electronic plan rooms

• 4D Scheduling

uses an accessible collection of IT tools in meaningful support of on-site operations. In its most advanced forms the ICS optimizes a diversity of cost effective IT tools to provide a proactive performance enhancing project site, in effect an intelligent construction site. To allow for extended on-site IT integration, and create a more intelligent construction site, it is important for users to identify and understand these intelligent tools. Denotation of these tools into categorical domains provides an outline for tool accessibility and future usage. Therefore to aid in their understanding an operational hierarchy of intelligent tools and their task utilization opportunities are presented. These tools, as shown in Table 1, have been synthesized within four domains that comprise ten operative functions within on-site construction management. Table 1 presents the four domains as; 1) Digital Imagery Processing; 2) Electronic Data Interchange; 3) Process Modeling and Visualization; and 4) Virtual Collaboration. Within each of these domains are broad operational functions and technical tools. As stated earlier, the diversity and effectively integrated use of these tools provides for increasing levels of site intelligence. 3.1 Digital Imagery Processing (DIP) In its simplest form, DIP can be characterized by capturing field images using digital cameras for later user processing. Several techniques, each with increasing knowledge sophistication and intelligence levels are available for on-site usage. An example of these intelligent tools/techniques that are operative within a DIP domain are; 1) dynamic scheduling using real time web cams or time-lapse video recording/playback; 2) digital still/motion capture and Internet image distribution and database archiving for subsequent knowledge management. 3.2 Electronic Data Interchange (EDI) This domain is uniquely defined as electronic data acquisition and exchange using automatic data collection instruments/devices and field-placed data sensors, and archiving the data on permanent storage media. Among the intelligent tools that perform various tasks within this domain are; bar coding devices for material control; web-cams linked to project specific websites; pocket-PCs with electronic forms for automated data entry and reporting; and wireless networks that incorporate RFID devices.

Ework and ebusiness in architecture, engineering and construction

968

3.3 Process modeling and visualization Process modeling and visualization provide affordable IT tools that quickly and realistically depict data in a visual format. The strength of these tools is their capability of transforming voluminous amount of construction related spatial data into a graphical and visual manner that instantly improves comprehension. Significant on-site performance gains can be expected as a result of increased field accuracy and process clarity. There is considerable work being done in areas of 3D visualization, virtual construction environments, and 4D scheduling. Although there are some aspects of this domain to performance enhancements true process modeling is weak and lacks the integration with visualization due to constrains brought about by the absence of common process vocabularies. Therefore the strengths of this domain are in product sequence animations, and virtual environments. 3.4 Virtual collaboration Virtual collaboration allows the project team to share a 24/7 virtual site available to all actors on any construction project. The capabilities of virtual collaboration tools include shared documents linked to a project database accessible through a PSW; teleconstruction capabilities using web-cams; and shared process and product models developed from VRML or 3D animations. The concepts of online web-chats and web conferencing have become more integrated into people’s work-lives and more and more people are using simple web technologies to communicate in text, sound, and visual methods. Among the ICS collaboration functions and tools are: Web-based Project Management, Electronic Document Management, and Electronic Plan Rooms. 4 THE INTELLIGENT CONSTRUCTION TOOLBOX OR IT TOOLBOX The construction industry is communication dependent and currently comprises a diverse mixture of electronic and paper based information exchanges. Unlike manufacturing, construction is a collaborative activity in all phases including not only assembly work but work that occurs prior to and after the assembly processes. The authors define an Intelligent Construction Toolbox, or IC Toolbox, comprised of a collection of current available IT tools that would allow for performing different tasks and processes under the four domains described above. The authors consider a baseline ICS IT toolbox to include a telephone, a fax machine, and a personal computer linked to the Internet with a basic email account. Anything beyond this baseline is a smarter and more ICS. Figure 2 shows a collection of available intelligent technical tools, and the linkages between the tools and the defined domains based on the different levels of integration that exists for problem solving using these tools. As depicted in Figure 2, the four domains contained within the ICS are connected to the avialble technical tools using one-to-many relationships. The technical tools support multiple domains. Each domain contained within the IT Toolbox are interrelated with

Intelligent construction sites (Icss)

969

other domain tools. For example, digital prototyping is a tool that has primary capabilities for use within the domains of Digital Imagery Processing and Process Modeling and Visualization. The objective of an ICS is to have access to IT tools and for the user to select the right tool for the right task at the right time. Notwithstanding improvement in e-communication, information delivery and field processing, construction remains a traditionally paper-bound enterprise. Communication among field office participants is done electronically yet the actual presence of information within in the field environment is predominately paper-based. No one is constructing by looking at the actual electronic object. Paper drawings are used to extract information for construction, assembly, and placement. Due to changing stakeholders, the construction process requires a set of unique, yet standardized electronic tools for on-site information exchanges and performance improvements. An identifiable set

Figure 2. Intelligent Tool Box showing domain, function, and tool structure.

Ework and ebusiness in architecture, engineering and construction

970

of standard, yet customizable tools is available within the defined domains of the ICSs IT toolbox. 5 PROBLEM SOLVING USING THE IT TOOLBOX ON AN ICS Adrian (2002) notes that approximately seventy-two percent (72%) of the construction workforce’s nonproductive time can be attributed to the lack of information or due to information that is not available when needed to allow work to continue without delay, disruption or error. Forty percent (40%) of this lost time can be characterized as waiting for either instructions or resources, while twenty-two percent (22%) of lost productivity is the result of late, inaccurate or poor information exchanges. The other ten percent (10%) is a result of rework or defects list corrections. The absent of efficient and accurate information exchanges are consistently generating non-productive field activities. Table 2 shows a matrix of opportunity for solving many of these performance deficiencies through the avocation and implementation of ICSs domain intelligent tools. The primary benefit of an ICS using tools from the IT toolbox are the reductions in communication times and the costs associate with using a paper based documentation, which has an inherent delivery and accessibility time lags. The potential problem of the construction site is an ineificient communication flow through a paper-based system that relies on a baseline ICS.

Table 2. ICS Task/Tool selection matrix. Domains Non-productive tasks Waiting on instructions Rework Late or inaccurate information Multiple material handling Punch list work

DIP EDI Process modeling & visualization

Virtual collaboration

Intelligent construction sites (Icss)

971

Figure 3. Multiple material handling task solution using Intelligent Tools. The IT toolbox can assist managers by producing a more ICS through the prevalence of using domain specific IT tools for resolving on-site problems. It is conceivable that an effective ICS can reduce on-site errors, minimize rework, improve safety and security, and provide a highly efficient supply of materials and products to the site. Figure 3 outlines an example strategy for an ICSs IT tool selection to solve an information flow problem that is resulting in multiple material handling. A specific inquiry is required to determine what tools are available and what tools can be used to assist in solving the problem. In this example the material is bar coded and identified upon receipt and installation through a mobile computer equipped with a bar code reader. The inventory data is linked to an e-form to a custom database accessible through an internet based PSW. Another task may require different tools to solve the specific operational concerns. For instance, many stakeholders initiated changes during the process and a simple change that is not relayed to the appropriate field personnel in a timely fashion can result in more extensive costs by having to do rework without compensation. Thus poorly communicated changes that lack accurate and timely information exchanges will accrue addition non-productive activities. The availability of IT tools can have the potential to quickly provide the needed information in a usable format at the right time. The primary goal of the IT toolbox is to provide an ICS with the ability to correct informational exchange problems in a manner that improves performance.

Ework and ebusiness in architecture, engineering and construction

972

6 SITE INTELLIGENCE QUOTIENT (IQ) To achieve an Intelligent Construction Site with a relative high IQ requires an extensive array of IT tools and the ability to effectively deploy these tools in a manner that benefits on-site performance in areas of productivity, safety, quality, and timeliness. The more extensive the IT toolbox and the more cross domain capable, the higher the Site IQ. One should be careful to not equate an ICS with a higher IQ to an ICS that has higher performance due to a higher degree of IT tool utilization. This is equivalent to having book sense but no common sense. One must always remember a tool is designed to improve not hinder performance. Care must be taken to select the right tools and prevent the accumulation of too many tools as a smart toolbox may make a dumb site. Thus to create an intelligent ICS, several tasks must be addressed and successfully implemented. Among these task implementation requirements are: • An analysis of project complexities and operational uncertainties, • Identification of on-site operational strategies, • The examination and valuation of systematic ICS IT domains, • The determination of needed internal ICS functional techniques, • The identification of needed on-site IT tools to meet the defined IT needs, • The stocking of an ICS IT toolbox that meets the on-site operational strategies, • The deployment of these tools in appropriate combinations to enhance on-site performance. A successful ICS uses collaborative and systematic efforts to identify and evaluate on-site shortcomings and fills its IT toolbox accordingly By careful understanding of the IT toolbox domain/ftmction/tool structure a user should be able to effectively select the right tool for the right task. As several IT tools may successful operate within the four interdependent domains, an ICS needs to understand its on-site/off-site information needs, its operational concepts, information exchange parameters, tool technology, and deployment strategies to create an ICS that’s truly intelligent. 7 CONCLUSION The Architecture/Engineering/Construction (AEC) industry has adopted and considered a wide array of useful, meaningful, and accessible information tools in support of construction operations. To understand the operational benefits from these tools, their informational contributions in making an ICS are explored. The breadth and depth of intelligent tool usage yields the site IQ.

Intelligent construction sites (Icss)

973

REFERENCES Abeid, J. and Arditi, J. (2002). Linking Time-Lapse Digital Photography and Dynamic Scheduling of Construction Operations. Journal of Computing in Civil Engineering, Vol. 16, No. 4, 269– 279. Adrian, J. (2000). Ten New Themes for Productivity Improvement, Construction Productivity Newsletter. Vol. 18, No. 6. Dawood, N., Akinsola, A. and Hobbs, B. (2002). Development of automated communication of system for managing site information using internet technology. Automation in Construction 11 (2002)557–572. Egan, J. (1998). Rethinking Construction. London, HMSO. Latham, M. (1994). Constructing the Team. London, HSMO. Olgesby, C., Parker, H. and Howell, G. (1989). Productivity Improvement in Construction. New York, McGraw-Hill. Stein, B. and Reynolds, J. (2000). Mechanical and electrical equipment for buildings. New York, Wiley. Sun, M. and Howard, R. (2004). Understanding I.T. in Construction. London, Sporn Press. Unger, S. (2002). The trend towards an Internet-based communication standard in the A/E/C industry. A Construct-ware White Paper, Atlanta, Constructw@re.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Organizational point of view for the use of information technology in construction projects P.Praper Faculty of Civil Engineering, University of Maribor, Slovenia ABSTRACT: Not one project is carried out as whole by only one company. The companies may have different roles in projects: they could be investor, main contractor or subcontractor. Setting up the organizational schema of the project is a hard and responsible task of the main project system. The communication and responsibilities must be set up simultaneously with the setting up of the organizational schema. The IT technology used on the side of the main project system has open enough that other participant in process can be incorporated into it and on the other side the IT technology used should be flexible enough that in can adapt to the defined role. In this paper the conclusions and guidelines are made on the data and characteristics of the projects, phases of the projects and organizational schemes. The data was gathered in a relation database by project manager during the project lifecycle.

1 INTRODUCTION In this paper, the business model is construction SME’s, where the project manager usually works on several projects at the same time. It is well known, that the construction industry is fragmented and construction projects include diverse enterprises ranging from engineering to construction, to material production, to several pre and post construction services. There are many different points of view on the project and at least as many organizational approaches: from pure project organization to matrix and functional approaches (Litke H. 2002). When we take into consideration the whole project life cycle it is essential to clarify the roles of the participants. The definitions of roles in particular project is especially important because the construction companies are in different roles; from investors on the market to main contractor to subcontractor. Also the term project manager is often confusing while as on the same project the designers have a “project manager”, the building company has a “project manager” and the investor also has a “project manager”. When we talk about IT in project management it is wrong to isolate only some activities or phases. IT support must in the first place take into consideration the whole project cycle, although it is possible support only for required areas. On the other hand it is essential to classify and standardize the project management process. At

Organizational point of view for the use of information technology

975

present there are no sufficient standards for important tasks in planning and management. (Kuhne C. & C.Leistner 2002) The purpose of this paper is based on case studies to open some dilemmas and reasons and to clarify the relations important in this process. 2 PHASES AND ORGANIZATIONAL HIERARCHY Construction projects have many different and independent people or institutions involved within a particular phase or in several phases of the project. There are several classifications of the investment project phases and relations among them. The most overall division of the whole project life cycle includes the concept of the project, design, building and exploitation. When we talk about a construction project, often only the Design planning, Cost estimating and scheduling, Technical design, Invitation to bid, Building, Project billing and controlling are mentioned (Kuhne C. & C.Leistner 2002). But when we consider the project manager’s point of view towards the whole life cycle of the project it is obvious that the real estate procedures such as acquiring real estate, breaking up an estate and geological research play important roles in time, cost and quality estimation. The relations among them are usually much more complex than they look on the first sight. On the basis of the different professions involved, legislation and stages of the construction project, the following supporting processes have to be added into whole life cycle of the project: – Initiative, Start up – Real estate procedures – Spatial plan procedures – Evaluations of all activities – Agreements – Supervision – Exploitation, maintenance. All of the above phases require collaboration and the exchange of documentation, and all of them produce documentation of the project When we talk about successful realization of the cost, quality and time plan, all the phases have to be managed and IT is the tool of optimization. According to Hauc the project includes the project and all systems included in the project. (Hauc A. 2002) The project system consists of: main system, managing system and execution system. The main system, that is usually investor or beneficiary, develops a vision for the project, copes with operational and strategic chance on the project and sets the general direction of the project. Managing system has the task of coping with the complexity of developing and implementing a management system for the project, maintaining oversight of the efficient and effective use of resources designing and developing the management functions, organizing, motivating, directing and controlling, the project, ensuring the

Ework and ebusiness in architecture, engineering and construction

976

communication process involved in the project works effectively. The project manager is part of managing system and must both: lead and manage. The execution of the activities is the task of external executants and internal executants—subcontractors. They are chosen from inside the company or on the market according to the rules of tender. On a project as a whole we can define a project system, but executants of a particular task see only their subscriber and supervisor. 3 CASE STUDY With aim of optimizing the management process we have started to collect project management data from the projects. The basis were MS Excel tables that every project manager have had on their computer and later also on networks. The upgrade to a relation database was logical progress, where all employees registered every event and document to form, that was related to the database. For this purpose we have developed a simple and practical project management tool called ITvPR, developed simultaneously with the progress of the project. Microsoft Access has been chosen for Database engine. Even thought it is not considered a real database engine, it has several advantages: like Excel it is part of MS Office, easy to use, widespread all over the world and it can be exported to more powerful database engines such as SQL Server. The database consists of several entities: companies, prqjects, persons involved in the process, send and received post, offers, traveling costs, cash flow, contracts, and invoices. Over three years time in database there were about 100 project managed by 6 project managers. Projects have been deeply analyzed from the inside, i.e. from project manager’s side. Comparison of them all would exceed this paper, so here are descriptions and organizational schema of two of them. First is the investment in new shopping, second is the reconstruction and adaptation of a castle into a library. Both projects have similar budgets and useful business area, but other characteristics such as complexity, speed, repetition and organizational approach are quite different. The shopping center is a new building for known users in as short a time as possible (less than a year from initiation to the realization). The project management spent approximately 1790 hours; there were 15 contracts with direct subcontractors and they made out 55 invoices. Reconstruction of the castle into a library started in 2001 and it is scheduled to finish in October 2004. The project is financed by the Ministry for culture and 4 municipalities. Until now the project management has spent approximately 2825 hours; there were 64 contracts with direct subcontractors and they made out 158 invoices.

Organizational point of view for the use of information technology

977

4 ORGANIZATIONAL SCHEME Figures 1 and 2 show the relationships, main phases, participants and deciding levels of the described projects. At the top of each figure there the authorities and legislation that give the principle rules and framework for the specific location. Under them are the diversified levels of the participants in the process. The connections among them show who commissioned whom. Some link cross, which means conflicts. The collision of interest is especially problematic when the commission is given across two or more levels as is the case in the first project. Contractors who subscribe to different decision levels are also quite problematic. In such cases one usually subscribes quality while the other one is the financier. Another problem of the project pointed out in Figure 2, is that the role of project management is not well defined. The investor in this case is a public institution, so all commissions are contracted with this public institution, so the external project management have only a consultant’s role and cannot give effect to commissions.

Figure 1. Shopping center project.

Ework and ebusiness in architecture, engineering and construction

978

Figure 2. Renovation of castle into library project. When we view the figures from left to right we can see the time component of the project. From both figures it is evident that at beginning of the project, the project manager was already in contact with the authorities and the beneficiary and so was well introduced to their wishes and constraints. The orders, documentation and payments use the same connections as the deciding and commission connections and this is why they are so important. 5CONCLUSIONS The collaboration on the project involves multiple groups and departments inside and outside the company. The type and size of organizations taking part in the construction projects can be very different. When the company buys or develops IT support for project management it has to consider their own role in the project’s life cycle and in the organization concept because the collaboration with other participants is essential. The beginning of the project is however the most important phase and has a major impact on the results of the project, although it represents only a minor financial part. The task of the project management is to define, on the basis of experience and knowledge, the organization of the project and IT support. At a beginning of the project the main concept of information and communication technology have to be already defined and contractors who enter into a particular phase just have to accept rules. That is why it is so important that the main investors such as Ministries, Municipalities, financial institutions, residential ftmds and construction companies are aware of the benefits of good organization and together with project managers and

Organizational point of view for the use of information technology

979

consulting engineers should understand the importance of the standardization of project management and organizational levels that can then be IT supported. However the responsibility and control of the project is up to the project manager who has an interest for IT support while it means good results in cost, quality and time sense. He must define the organizational scheme so that it has fewer and fewer crossings and commissions over diiferent decision levels. REFERENCES Bennett J. 1985. Construction project management, UK: Butterworths. Litke H. 2002. Projekt—management. Freiburg im Breisgau: Haufe. Hauc A. 2002. Projektni management. Kuhne C. & C.Leistner2002. Benefits of using product and process model data in project management. Proceeding of ECPPM 2002. Netherlands: Balkema. Psunder I. 1998. Strategy of quality in building projects. Proceedings/14th World Congress on Project Management. Ljubljana: Slovenian Project management organization.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Virtual reality at the building site: investigating how the VR model is experienced and its practical applicability S.Woksepp NCC Construction Sverige AB and eBygg—Center for Information Technology in Construction, Department of Civil & Environmental Engineering, Luleå University of Technology, Sweden O.Tullberg Department of Structural Mechanics, Chalmers University of Technology, Sweden T.Olofsson eBygg—Center for Information Technology in Construction, Department of Civil & Environmental Engineering, Luleå University of Technology, Sweden ABSTRACT: The paper presents an investigating on how a visualised Virtual Reality (VR) model is experienced and assessed by the workforce at a building site. It also provides insight of the basic information flow requirements. The questionnaire involved a total of 93 participants, all of whom were involved in the building project. The VR model in question was realistic, as the majority of the participants were positive about using it in their profession. The participants also felt that the information flow at the building site was insufficient today and that a VR model can have a beneficial effect on information transfer and co-operation. Further studies using VR modeling in construction is necessary to provide knowledge for practical implementation.

1 INTRODUCTION “Designing all but the simplest of products and artifacts on paper has now had its day. Moving to VR affords greater clarity and understanding, facilitates simulations and testing, and as a result, great savings”. Cochrane(1997) The most common way of distributing technical information at a building site is by means of 2D CAD drawings. It is often necessary to consult more than one drawing to perform a single task on a site. There is a clear need for ready access to these drawings in updated, correct form. In addition, the information should be easy to understand in order to avoid misunderstandings and costly mistakes. The use of Virtual Reality (VR) offers one possible solution. However, there has been little empirical investigation of VR

Virtual reality at the building site

981

technologies by companies in the construction sector (Whyte 2001). To determine whether VR can provide a useful complement to traditional building techniques and to 2D CAD, the requirements for the practical use on daily basis have to be determined. In addition, the design of a VR model also needs to consider the specific needs from different groups of the users, i.e. construction workers, site managers, designers and other persons or groups involved. Even if VR has been shown to be effective for visualising information in many other contexts, its broadbased use within the construction industry is yet to come. However, many research centers and government laboratories have provided the opportunity for construction companies to make use of their VR facilities. An example of VR system used by the construction companies is Bechtel’s WALKTHRU (WALKTHRU 1991) available since 1980s, which uses real-time animated images and links together three-dimensional graphics packages and engineering databases (Retik & Shapira 1999). Roupé et al. (2001) examined how users experienced a detailed VR model of an office building. Although their study targeted users of office premises and thereby related to the building design, it provided indications of how individuals who are not accustomed to VR technology experienced a VR model. The results suggested that the tested VR model was perceived as being realistic. Calderon et al. (2000) studied communication between members of design and construction teams, their clients and other, indirect stakeholders. However, there is a lack of adequate research on the use of VR during the construction phase and that VR so far has relatively few practical applications in this area. The result presented in this paper is a part of the project “Applied Virtual Reality for Large and Complex Buildings” (VR/lcb), (Woksepp 2001, Woksepp & Tullberg 2001). It is an effort to quantify the attitudes of using VR at the construction site with statistical analysis. The questionnaire was designed with funnel technique, which involves starting with general questions, or statements to which the participant is to respond, followed by indepth questions or statements designed to study the respondents’ attitudes toward specific issues (Dahlström 1970). All the statements and questions have a set of reply alternatives. The framing of the statements and questions used in the questionnaire accounts for the standard of attainment in this type of context (Lantz 1993). 2 VR SYSTEM AND VR MODEL The software and hardware used in the study are commercial and available on the market. The investment can be described as reasonable, i.e. suitable not only for large but also for small and medium-sized enterprises. The VR model used was a prototype of “Centralhuset”—a hotel and office block completed in Gothenburg, Sweden, in November 2003. The model was produced by including a number of different 3D modelling tools, such as 3D Studio (Autodesk™), SolidWorks (SolidWorks™), AutoCAD (Autodesk™) and Xsteel (Tekla™). The VR model, visualised in Division MockUp (PTC™), describes the construction of “Centralhuset”, in particular its steel structure, foundations, adjacent surroundings, frontage, beams and floor components and the incoming rail tracks.

Ework and ebusiness in architecture, engineering and construction

982

For the VR demonstrations, two PCs were employed: a 256 Mb RAM/18 Gb HD 1 GHz SGI Zx 10 with a Wildcat II 5110 graphics card and a 256Mb RAM/18Gb HD 866 MHz Compaq SP750 with a Wildcat Pro 4110 graphics card. The VR visualisation can be described as desktop immersive. A Proxima UltraLight X350 projects the VR model on a screen, while a Magellan Space mouse is used to navigate in the Virtual Environment. The VR equipment was chosen for its functionality, price, flexibility and full compatibility with CAD. Division MockUp (PTC™) was used for the VR visualisation. Approximately 10,000 objects were used to produce the VR model of “Centralhuset”. The VR model in the study included the following environments: – the adjacent surroundings, – the excavation, the piles and foundation, – the steel structure and the prefabricated floors, – parts of the facade, – the railway station, – the site office, the crane and – a proposal for office space.

Figure 1. The steel structure.

Virtual reality at the building site

983

Figure 2. Foundations and piles.

Figure 3. A proposal for office space. Figure 1–3 shows some of the included environments in the VR model. The input to the VR model came from 2D CAD drawings and some 3D CAD model of the steel structure. Although the model is extensive, the size of the resulting VR files is only 85MB. To date, approximately 350 man-hours have been spent to create the virtual prototype, at a cost of approximately EUR 35,000.

Ework and ebusiness in architecture, engineering and construction

984

3 RESEARCH AIM The questionnaire was designed to study how the visualised VR model of “Centralhuset” in Gothenburg, Sweden, was experienced and assaessed by users and the extent to which a model of this kind could complement the 2D CAD drawings that are generally employed in this kind of context. The operational use of VR at the building site was the primary concern. By studying people who had little or no experience of 3D CAD or of VR, we hoped to reveal the attitudes of the average person working at a construction site rather than those of a 3D CAD or VR expert. 4 METHOD 4.1 Design The questionnaire consisted of 20/21 questions or statements (21 directed at the building owner representatives, NCC Property Development). To obtain a general view of the participants as individuals, the questionnaire started with three questions pertaining to individual characteristics (age, profession and computer skills). Then, statements for investigating participants’ attitudes towards the use of the VR model were presented. Subsequently, various statements relating to the information flow at the building site were presented. The questionnaire closed with a section containing general statements concerning the use of a VR model in the respondents’ own profession. The statements in the questionnaire as a whole have the same formulation for all participants, except in this final section. Here, statements about customer relations were presented for the representatives for the building owners. All statements were expressed as assertions rather than negations. Although leading questions or statements should be avoided in a questionnaire, (as they could reflect the position the researcher, Ekholm & Fransson 1994), we nevertheless decided that an approach of this sort was best for investigating the main questions of the study: 1 How will the VR prototype be envisaged, experienced and assessed by the users, and 2 To what extent can a VR model complement the use of 2D CAD drawings. The questionnaire comprised of nine pages, including a description of its aims, a statement regarding the confidentiality of the results, the questions and statements and space for the participants to write in any additional comments they wished to make. A Likert scale was employed to convert the participants’ responses into numerical data. The Likert technique involves various statements being presented and participants being asked to express agreement or disagreement on a five-point scale: “Strongly agree” (5), “Agree” (4), “Undecided” (3), “Disagree” (2) or “Strongly disagree” (1). A seven point-scale can also be applied using the Likert technique (Trost 2001). Since numerical values represent the participants’ attitudes expressed in points, different values represent different attitudes (Patel & Davidson 1994). The Likert scale was used for all the

Virtual reality at the building site

985

questions in the questionnaire, with the exception of questions relating to personal characteristics, first contact with VR, information flow and the final questions directed at the building owner representatives. The collected results were and converted into numerical values. The mean and the standard deviation for the participant group as a whole were calculated for each statement. The standard deviation indicates how the obtained scores from the participants vary around the mean value (cf. Niles 2002). The results were stored in a database and the statistical analysis was made in Matlab, a numerical software package from MathWorks™. 4.2 Procedure and participants The procedure was to deliver questionnaire to the participants at the building site Centralhuset in groups of 1–20 individuals at a time. The fact that the building was halfcompleted made it particularly easy for participants to compare the VR model with the erected construction, thereby facilitating comparisons of the expressions “Virtual Reality” and “Reality”. The project leader started a test session giving a short introduction of the research project and handing out the questionnaires. The participants began by answering the introductory part concerning the personal details and characteristics. Then, the concept of VR was presented followed by a demonstration of the VR model. The participants continued by answering the remaining questions and statements in the questionnaire. The project leader was present throughout the session to provide support for the participants if any of the questions or statements were difficult to understand. It took approximately 20 minutes for the participants to complete the questionnaire; including the time taken by the VR demonstration. The majority of the people involved in the construction of “Centralhuset” participated in the study. Figures 4 and 5 shows the distributions in occupation and age of the 93 respondents. The construction workers were the most heavily represented category. The age ranged from 20 to 62 years. Differences due to gender could not be investigated, since too few women took part in the study. The majority (53 of 93) of the participants agreed with the statement “I consider that I have good computer skills”. To the statement “This is my first contact with Virtual Reality”, 67 people agreed and 26 disagreed. The majority of the participants that previously had experience with 3D modelling and/or with VR were designers.

Ework and ebusiness in architecture, engineering and construction

Figure 4. The participants’ occupations.

Figure 5. The age of participants.

986

Virtual reality at the building site

987

5 RESULTS 5.1 The questionnaire The main goal of the study was to establish whether a VR model could be a practical and reliable information tool at the building site. We also wanted to investigate the possibilities of the VR technology in improving the flow of information and co-operation between the people participating in the construction work at the building site. The result is not conclusive, but can serve as guidance rather than definite due to the limitations of the study. The main results from the study are summarized in Tables 1, 2 and 3. The final part of the questionnaire was the section that generated the most intense discussions. Comments such as “This is great, but how do we implement it in our everyday work?” or “Interesting, but can we save any money by using a VR model at the building site?”. Further research is needed in order to provide answers to these questions. However, the majority of the respondents were positive about using VR models at the building site, as shown in Table 3. Some concerns regarding the financial benefits and of how well they could manage a VR model was expressed. Despite their positive attitude to using VR models, most of participants still felt the need for further investigation of the benefits of VR.

Table 1. Participants’ attitudes towards VR regarding impressions, navigation and co-operation. Virtual Reality (VR)

Mean value

Standard deviation

First impressions at the VR demonstration The VR model provides a better overview of “Centralhuset” than 2D CAD drawings do.

4.57/5

0.54

The Virtual Reality model of “Centralhuset” has an appearance that inspires confidence in it.

4.30/5

0.69

Details show up better in VR than in 2D CAD drawings.

4.12/5

0.68

It is easier for me to explain the details I am involved with professionally using a VR model than using 2D CAD drawings.

4.16/5

0.80

Having the ability to navigate within the VR environment and thus being able to scrutinise the model involved from different angles helps me to understand details.

4.50/5

0.70

The co-operation I have with my colleagues within the same occupational group is facilitated by using a VR model.

4.01/5

0.73

The co-operation I have with colleagues from other occupational groups

4.20/5

0.72

Help of navigation in the handling of details

Co-operation by use of a virtual environment

Ework and ebusiness in architecture, engineering and construction

988

is facilitated by using a VR model. Details in areas outside my areas of professional expertise are easier for me to understand with the aid of a VR m odel.

4.30/5

0.73

5.2 Additional comments In addition to answering questions and responding to statements, the participants could also add comments in the questionnaire. Most of the comments related to the degree of detailing and the cost of using the VR model. Other comments related to when the VR model was likely to be feasible. The highest potential of the

Table 2. The participants’ present and desired future access to information. Information handling

Mean value

Standard deviation

I already receive enough information in my job without the help of VR models.

3.55/5

0.77

I’m satisfied with the way information is distributed to me now, without the help of VR models.

3.40/5

0.75

Personal situation

In my occupation, I receive information primarily from the following sources (several alternatives can be selected):

1.

2D CAD drawings

2.

3D CAD drawings

3.

Personal contacts

4.

By telephone

Virtual reality at the building site

989

5.

By fax

6.

Through the internet

7.

LAN (Local Area Network)

8.

From literature, brochures etc.

9.

From other sources

In my future job situation, I would like to receive information mainly from the following sources (several alternatives can be selected):

1.

2D CAD drawings

2.

3D CAD drawings

3.

Personal contacts

4.

By telephone

5.

By fax

6.

Through the internet

7.

LAN (Local Area Network)

8.

From literature, brochures etc.

9.

From other sources

10.

From Virtual Reality models

Table 3. Summary of the participants' attitudes towards using the VR model in their work.

Ework and ebusiness in architecture, engineering and construction

990

Final section* Using VR models in one’s own work I think I would benefit from using VR models in my work.

4.30/5

0.68

I could imagine using VR models in my work.

4.28/5

0.75

Convincing me of the benefits of Virtual Reality would require: (several alternatives can be selected):

1.

Nothing, I am already convinced

2.

Successful pilot projects

3.

Economic analysis

4.

VR presentations at the workplace

5.

Better technical knowledge

6.

Other factors

*Two additional questions for the representatives of the building owner are presented in Section 4.2. In addition, all the participants apart from the representatives of the building owner answered the first statement in the “Final section”.

VR model was believed to be when a new task was about to be performed rather than using it all the time. The rest of the comments related to problems associated with keeping the VR model updated and the need for adaptation to the conditions on the building site. The representatives of the building owner responded to two additional statements: – I believe that using VR models can give me a more favourable position in relation to my customers.

Virtual reality at the building site

991

– I believe that by using VR, I can reduce the costs of errors sufficiently to cover the costs of the modeling work. According to Josephson (1990) the reduction of errors is estimated to 10% of the total construction. The estimated cost of the VR model is 2%o. The last question is clearly speculative; however, the statement could give some indication on costs assessment. The first of these two statements yielded a more positive response, as all the participants selected “Strongly agree” or “Agree” (Mean—4.5, Standard deviation— 0.58). The second statement received a response that, albeit it pointed slightly in the direction of agreement (Mean—3.25, Standard deviation—0.63), has to be considered “Undecided”. However, since only four building owner representatives participated, the response is only indicative. A much larger number of participants is needed to ensure reliable responses. 6 DISCUSSION The aim of the questionnaire was to investigate the way work force involved in constructing the “Centralhuset” building in the city of Gothenburg, experienced and assessed the VR model as well as the intended use for information purposes. The VR model focused primarily on the supporting structure, the foundations and the prefabricated floor components of the building. We expected that some of the occupational groups could have more use for the model than other groups. Therefore, we endeavored to perfect the original version of the VR model to make it as suitable as possible for all the occupational groups involved. In the questionnaire, three objective personal characteristics of the participants; age, occupation and computer skills, were determined. No relationship between these characteristics and the views or attitudes that the participants expressed in their responses could be found. Although we did not perform any significance tests, the reasonably high mean values combined with low standard deviations obtained for most of the test items relating to the participants’ attitudes and assessments, indicates a high degree of consensus. This gives a strong indication of the conclusions drawn. 7 CONCLUSIONS AND FUTURE RESEARCH The results of the study suggest that there is a genuine need to improve the information flow at building sites. The usefulness of technical aids such as VR, appears to be obvious, especially as a complement to the 2D CAD drawings. Indications that can inhibit integration of VR into the building process was also found in limited technical knowledge and financial considerations. The present procedure of distributing information by means of 2D CAD drawings is ineffective. Moreover, planning in 2D rather than directly in 3D considerably increases the cost of producing a VR model. The views of the respondents on the different issues in the questionnaire varied very little, between different ages, occupations and computer skills. Although the construction

Ework and ebusiness in architecture, engineering and construction

992

workers were the group whose computer skills were most limited, they were particularly positive in their assessment of the advantages of using VR in the construction process. The fact that they receive information largely from 2D CAD drawings and personal communication may well have contributed to the positive attitude to new and richer forms of communication media. This type of VR model needs to be carefully developed to complement to the information given in 2D, especially in the sections and in details that are difficult to grasp with 2D drawings. Therefore, we recommend that specialists on VR are used to produce and maintain the model of the construction process. It is also important to inspire and give confidence in the technology to people who are going to use the VR model. Otherwise, the model will not be used in practice. The developers of VR system have to adapt their systems to the needs in order to be useful for the construction industry. Further studies regarding the planning and performance of the construction work using VR modeling are therefore necessary to provide the necessary facts for implementation. ACKNOWLEDGEMENTS The study received financial support from IT Construction & Real Estate 2002, NCC AB and Chalmers University of Technology. We are grateful to everyone who took the time to participate in the study and to provide the necessary feedback. Special thanks are also due to the companies at the building site; specifically NCC AB and its sub-contractors, for allowing us to interrupt their work so as to administer the questionnaire. REFERENCES Calderon, C.P., van Schaik, P. & Hobbs, B. 2000. Is VR an effective communication medium for building design? Proceedings of the Virtual Reality International Conference, Laval, France, 18–19 May. Cochrane, P. 1997. 108 tips for the time travelers. London: Orion Business Paperbacks. Dahlström, E. 1970. Interview and survey techniques. Stockholm: Natur och Kultur. (In Swedish). Ekholm, M. & Fransson, A. 1994. Practical interview techniques. Stockholm: Norstedts Publishing House AB. (In Swedish). Josephson, P-E. 1990. Quality in building—a discussion about quality error costs, Report 25. Department of Building Economics and Management, Chalmers University of Technology, Gothenburg. (In Swedish). Lantz, A. 1993. Interview methodology: To carry out an interview. Stockholm: Studentlitteratur. (In Swedish). Niles, R. Statistics every writer should know: A journalist’s guide to using basic math to understand data and statistical research. http://www.robertniles.com/ (accessed 10/7/2002). Patel, R. & Davidson, B. 1994. The basics of research methodology: To plan, perform and report an inquiry (2nd edition), Stockholm: Studentlitteratur. (In Swedish). Retik, A. & Shapira, A. 1999. VR-based planning of construction site activities, Journal of Automation in Construction 8: pp 671–680.

Virtual reality at the building site

993

Roupé, M., Sunesson, K., Wernemyr, C., Westerdahl, B. & Allwood, C.M. 2001. Perceived meaning in Virtual Reality architectural models. Proceedings of AVR II & CONVR 2001. Chalmers University of Technology, Gothenburg, 4–5 October. Trost, J. 2001. Enkätboken (2nd edition), Stockholm: Studentlitteratur. (In Swedish). WALKTHRU PC Version 1.0, 3D Simulation, User’s Manual, Bechtel’s Software, 1991. Whyte, J. 2001. Business drivers for the use of Virtual Reality in the construction sector. Proceedings of AVR II & CONVR 2001. Chalmers University of Technology, Gothenburg, 4–5 October. Woksepp, S. 2001. Virtual Reality in Construction—a state of the art report. Internal publication 02:3. Department of Structural Mechanics, Chalmers University of Technology, Gothenburg. Woksepp, S. & Tullberg, O. 2001. “Centralhuset”: A Virtual Reality project at the building site. Proceedings of AVR II & CONVR 2001. Chalmers University of Technology, Gorthenburg, 4–5 October.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Evaluating competitiveness in construction industry: an alternative frame A.Y.Toprakli, A.Dikbaş & Y.Sey Istanbul Technical University, Istanbul, Turkey ABSTRACT: Competition is defined as the core concept in nonmonopolistic markets and competitive strategy and competitiveness of firms become an important area of interest among researchers. Accordingly, various frameworks and tools for analyzing competitiveness have been suggested mainly for manufacturing industries. Some colleagues also applied these frameworks for construction industry. However, there are some vague points emerged while analyzing competitiveness associated with scale and environment differences of construction industry. This paper analyzes appropriate categorization of construction environments for competitiveness tools application and aims at providing an alternative outline about examining competitiveness.

1 INTRODUCTION The start of the new century has brought new challenges for firms, industries and countries. Throughout its long history, competitiveness is highlighted once more as a crucial concern for enterprises to survive. Accordingly, numerous studies evolved for analyzing competitiveness issues. However, most of these studies aimed mainly for manufacturing industries and produce frameworks for analyzing different aspects of the term. These frameworks are usually employed for construction industry in second hand and scholars commonly apply these models to construction to see the immediate results of these tools. However it is obvious that there are major differences between the manufacturing industries and construction industry. So, application of these manufacturing industry oriented tools makes these analyses weak and suspect regarding construction industry environments. Competitiveness issue is important since it would provide different points of view to construction management studies and related applications. It is seen that despite growing concerns and research conducted about ‘competitiveness’ in construction, it is still a diffuse concept, and subject to many interpretations. These varying interpretations also make the term difficult to define properly and apply fittingly. Moreover, the actual scene about construction industry is usually distorted by these varying competitiveness models and tools and their applications. For this point this paper issues applicability, scope, strengths and weaknesses of some well-known competitiveness models and tools in construction industry and aims at bringing a categorization to business environments of construction industry for the changing characteristics of the competitiveness term.

Evaluating competitiveness in construction industry: an alternative frame

995

2 DEFINITIONS In following subsections, characteristics, environment of construction industry and competitiveness related issues are highlighted. 2.1 Characteristics of the construction industry In literature there are various definitions for the characteristics of the construction industry. The classification made by Sugimoto (1990) provides a more theoretical and fundamental one and the following list is formed to address some well-known and provisional characteristics of construction which diversify it from manufacturing industries. Experience-Good and Customization Characteristics: Customization of construction activities makes the output of construction production an ‘experience good’ and compared to a ‘manufacturing good’, whose quality is evident on inspection before purchase, the quality is understood only by using it after purchase. Specialization and Vertical Integration in Functions: The distinction between different types of firms is defined by Sugimoto (1990) as often blurred through vertical integration in functions. To illustrate, an engineering firm, which is basically considered as a design firm could ‘vertically integrate’ with all sorts of pre-construction activities and engage in project management and contractor branches. Unique bidding basis: According to Ball (1988) speculative construction can be seen as an extension of manufacturing in construction industry but bidding arrangements are special for construction for that every project is priced separately and distinctly in the form of a bid for that particular project. Relative subcontracting system: The subcontracting system is special in the construction industry since it permits the kind of flexibility required whereby various mixes of contractors and crafts must be mobilized to suit the unique requirements of a project. Ambiguity of goods and service production of construction firms: Particular to the specialization of functions of construction firms, there is a difficulty in defining their production: Although the construction industry is usually categorized as a service industry, firms in the construction industry produce both goods and services. International Involvement of Construction Firms: Manufacturing firms usually supply foreign markets in three primary modes: export, foreign direct investment (FDI) including equity-base joint venture etc. However, in construction industry, the ways of serving a foreign market is defined to be less straightforward because of the unique production process and subsequent industrial structure of the industry. Finally construction industry differs from manufacturing industry in referred points. According to Sugimoto (1990), theoretical treatment of construction production has not been sufficient enough to address these ambiguities in a systematic way and if construction industry and its productions are unique, it is theoretically misleading to apply ideas established for other industries to the construction industry and its firms.

Ework and ebusiness in architecture, engineering and construction

996

2.2 The environment of construction industry The structure and the environment of an industry directly influence the nature of competition between firms and accordingly the competitive strategies available to them (Porter, 1980). Construction is often reported as being a fragmented industry which is defined as ‘one in which no company has a significant market share and is able to influence considerable outcomes within the industry’. Furthermore, it is also defined as a geographically dispersed projectbased industry with markets that operate from local to the international level. Within this frame, the industry can be characterized as first, geographically dispersed and over-lapping market structures and second, is hierarchically structured in terms of company size (Langford, 2001). 3 COMPETITIVENESS Competitiveness, which is usually handled at three different levels, country, industry and firm level in literature, is a multi dimensional notion and originates from the Latin word ‘competer’ which means involvement in business rivalry for business markets (Momaya, 2004). Currently, institutions and academicians have been very prolific in proposing a definition for competitiveness (IMD, 2003) and this diversity can be seen as an indicator of the popularity of the subject but also of its complex nature. To draw upon the common elements of various approaches Lall (2001) defined competitiveness in industrial activities as a means of developing relative efficiency along with sustainable growth and should be understood more like a process than an absolute state, assessed in a relative sense as well. 3.1 Firm to national level competitiveness The fimdamental principle, which allows the distinction between concept of competitiveness of nations, industries and enterprises, concentrates on where the creation of economic value takes place. In current literature it is assumed that economic value is only created within the context of an enterprise and a nation’s environment hinders or supports this process through its policies (Lall, 2001). Momaya (2004) also states that understanding the competitiveness dynamics at the firm level is crucial for competitiveness. 3.2 Competitiveness related frameworks and models There are various competitiveness related frameworks exist in literature. Porter’s (1990) ‘Diamond Model’, ‘National Competitiveness Indices’ and Lall’s (2001) ‘Competitiveness Triangle’ are apparent ones in national level competitiveness issues. Five competitive forces model, value chain, segmentation matrix and three generic competitive strategies of Porter (1980, 1985) provide a base for industry and firm level competitiveness concepts.

Evaluating competitiveness in construction industry: an alternative frame

997

Most of these models are criticized for being weak or some improvement possibilities such as linked diamond models (Rugman, D’Cruz, 1993). In general, these models are also criticized for having business school or power school approaches (Lall, 2001); static/ dynamic characteristics, and analysis/deterministic point of views. Their scope of application is also varying from one model to another. Toprakli (2004) provides the scope, strengths and weaknesses of some models (Table 1), it is concluded that, qualities depending on microeconomics, ‘five competitive forces’ model and ‘value chain’ provide a backbone for all level of competitiveness studies.

Table 1. Strengths and weaknesses of competitiveness models and concepts (Toprakli, 2004). Scope of application

Strengths

Weaknesses

Diamond framework (Porter, 1990)

National industries

• Provides an analytical point of view • Supposed to be dynamic

• Business school approach • Culture and government impacts are lacking for construction • Multiple diamonds can provide a more realistic framework

Five competitive forces model (Porter, 1985)

Industry and firm • Provides an analytical level point of view • Depends mainly on microeconomics • Can be used in all levels

• Presents a static understanding • Provides an analytical point of view rather than a deterministic one

Value chain

Industry, firm and national level

• Provides an analytical point of view • Have a generic quality and applicable to all levels

• Usually there is a complex procedure to apply

APP model (Momaya, 2004)

Generic application

• Can be used in all levels • Meaningful to practitioners • Have qualitative features

• Presents a static understanding • Entrepreneurship and product issues are not identified.

KPI model (CBP, 1998)

Firm level

• Meaningfiil to practitioners • Can also be used among industries and nations • Systematic questionnaire and presentation

• Presents a static understanding • Based on indicators rather than theory

Ework and ebusiness in architecture, engineering and construction

TCV model (Shen et al. 2003)

Firm level

• Dynamic methodology through changing weights

998

• Lacks theoretical link • Depends solely on indicators • No qualitative side is identified

3.3 Applications of competitiveness frameworks in construction Several authors used theoretical frameworks to analyze construction industry. To illustrate, Betts and Ofori (1992) used Porter’s diamond model (1990) to provide a framework for strategic planning by construction enterprises and Oz (2001) applied it for Turkish Construction Industry. Yates et al. (1991) compare the US national construction industry by using Porter's (1980) five forces model. Huovinen and Kiiras (1994) build up ‘spearhead strategy’ by analyzing several frameworks such as the product-market matrix proposed by Ansoff (1965) and the five competitive forces framework of Porter (1980). Seymour (1987) reviews multi-national enterprise (MNE) theory and general theories such as Dunning’s (1977) eclectic approach which is criticized by Sugimoto (1990) as having a straightforward application of such modes unsuccessful for providing an appropriate interpretation for construction (Ofori, 2003). Lastly, Pheng and Hongbin (2004) extend Dunning’s eclectic approach with specialty advantages and developed OLI+S model to estimate international construction performance. There are also numerous models developed without particular reference to existing theoretical frameworks (Ofori, 2003). To exemplify, Momaya and Selby (1998) developed APP model for quantifying international competitiveness of the Canadian construction industry. The model is also used for firm level competitiveness understanding by Momaya (2004) for a different industry. There are also indicator based quantifying models exist for competitiveness. Accordingly, Hatush and Skitmore (1997) assembled a systematic multi-criteria decision analysis technique for contractor selection. Lai and Guan (2001) developed a model to assess a large contractor’s competitiveness by using several parameters (Shen et al., 2003). The last example of a similar study is conducted by Shen et al. (2003). Their study covers an assessment of contractor’s competitiveness by an examination of multiple parameters which is named as Total Competitiveness Value. Also, starting from 1998, Construction Best Practice (CBP) initiative in UK has developed Key Performance Indicators (KPI) as a comparative benchmark tool for construction industry. Finally, it can be concluded in parallel with Ofori (2003) that ‘there is no perfect framework for analyzing competitiveness for construction’ and ‘not any one in itself is sufficient for all sectors’. Similarly, Segev and Gray (1994) found out that there is no single appropriate model exists for constmction firms and advised to evaluate individual business units in terms of two or three typologies. It is seen that in one side there is a high use of theory in applied competitiveness frameworks for construction industry and on the other side, a gap between the indicator based models and theory. However indicator base and generic models are more meaningful to practitioners. So, there is a need to define a base to categorize relevant competitiveness studies, application areas and their interrelations for construction industry point of view. Furthermore, if Sugimoto’s (1990) conclusion about theoretical

Evaluating competitiveness in construction industry: an alternative frame

999

treatment of construction industry mentioned before considered, defining a new competitiveness framework for construction industry can be argued.

Table 2. Combined environment types: a frame for analyzing competitiveness in construction. Environmental types (Lansley, 1979 & Flanagan, 1994)

Characteristics

Useful models and tools for Competitiveness issues

• Firm level characteristics dominate competitiveness • Suppliers/Buyers (global level) highly important • Financial packages crucial • Importance of configuration and coordination (Porter, 1986) • Impact of global and multidomestic competition (Porter, 1986)

Firm level competitiveness models can be applied

Supra-national level Global environment

Multinational environment • Importance of firm level characteristics increase in competition • Alliance-specific advantages, system-based advantages and culturebased advantages highly important • Suppliers/Buyers (multinational level) • Financial packages important • Government support can be seen

National level competitiveness models can be partly applied. Firm level competitiveness models can be applied

Industry and national level International environment

• National and firm level characteristics dominate (Seymour, 1987) • International and national level suppliers are important • Government supports highly important • Culture, location is highly important

Diamond framework (Porter, 1990)

Common industry/ National environment

Common to all firms in the industry/national environment • Affects firms both directly and indirectly • Affected by demographics, technological and societal changes • The industry’s eisting and potential clients effective

Diamond framework (Porter, 1990) Five competitive forces model

Ework and ebusiness in architecture, engineering and construction

1000

• Suppliers (national level) are important • Central and local government departments Firm level Competitive environment

• Localized to the firm Value chain (Porter, 1980) • Dealing with industries and markets Five competitive forces model • Structure of demand (Porter, 1985) • Procurement forms used by clients • Suppliers (local), competitors • Availability of materials • Labor and subcontractors

Sub firm level Operational environment

• Unique to each firm • Subcontractors, human resources • Technology

Value chain

3.4 Key findings and suggestion Ofori (2003) stated ‘most of the authors in construction did not critically examine, or suggest refinements to, the frameworks they applied’ which also brings out another question; when they are modified according to the objectives of the construction industry whether it would cause any vital change in the models or not, remaining unanswered. Having analyzed the outcomes of Ofori (2003), and Momaya (2004), authors believe that a competitiveness understanding for construction industry could only be achieved by bringing a classification to the application areas of these models. Though having analyzed firm level competitiveness of software industry in India, Momaya (2004) also noticed that 'Many questions about competitiveness remain unanswered despite rich literature about concept. Some of the key questions such as: how can frameworks and models be adapted for a particular firm in a particular stage of development…remain unanswered’ (p. 53) and proposed a simple graphical matrix of firms’ survival and growth stages for the applicability of competitiveness models corresponding to capability. He adds that ‘There are many frameworks, models, theories on competitiveness; (however) integrated frameworks that can help practitioners to take key decisions on competitiveness are few. There is need for frameworks that can help select right tools from the industry perspective.’ Accordingly, authors suggest for construction industry extending Lansley et al.’s (1979) environment classification (Operational/Competitive/Common-National) by Flanagan’s (1994) three stage construction environment, i.e., international, multinational, global and to obtain a final base to evaluate competitiveness issues in construction (Table 2) which is also presented to take comment by the wider research community.

Evaluating competitiveness in construction industry: an alternative frame

1001

4 CONCLUSION Having the main objective as providing an alternative frame about evaluating competitiveness, which has been the growing concern in construction industry and a crucial field of interest among researchers; appropriate categorization of construction environments for competitiveness tools application is suggested in the paper. As understood from the stated vertical classification, better frameworks could be developed for future use in construction industry for researchers and practitioners. Another important point to be emphasized in the suggested categorization is it would help in determining hierarchical weightings for quantitative evaluations in a more systematic way. Considering the chaotic environment of competitiveness related terms and their applications, a process model could also be offered to guide practitioners about competitiveness issues in eonstruction industry. Besides, IT based applications could also be employed related with the developed process models. REFERENCES Ansoff, I.H. 1965. Corporate Strategy. McGraw-Hill, NewYork. Ball, M. 1988. Rebuilding Construction. Economic Change and the Construction Industry. Routledge, London. Betts, M. and Ofori, G. 1992. Strategic planning for competitive advantage in construction. Construction Management and Economics, 10, 511–32. Dunning, J.H. 1977. Trade, location of economic activity and the MNE: A search for an eclectic approach. In Ohlin, B., Hesselborn, P.O. and Wijkman, P.M. (eds) The International Allocation of Economic Activity, Macmillan. London, pp. 395–418. Flanagan, R. 1994. The features of successful construction companies in the international construction market. In Warzawski, A. and Navon, R. (eds), Strategic Planning in Construction: Proceedings of the A.J.Etkin International Seminar on Strategic Planning in Construction Companies, Haifa, Israel, 8–9 June, pp. 304–18. Hatush, Z. and Skitmore, R.M. 1997. Criteria for contractor selection. In: Construction Management and Economics 15 (1), E&FN Spon, London, pp. 19–38. Huovinen, P. and Kiiras, J. 1994. Spearhead strategy for cross-border exports within building market of EES countries. In Warzawski, A. and Navon, R. (eds), Strategic Planning in Construction: Proceedings of the A.J.Etkin International Seminar on Strategic Planning in Construction Companies, Haifa, Israel, 8–9 June, pp. 421–43. Lai, X. and Guan, K. 2001. A study of a large-scale contractor’s international competitiveness. In: Building Science Research of Sichuan 27, Sichuan Institute of Construction Science, China, pp. 73–75. (In Chinese). Lall, S. 2001. Competitiveness, Technology and Skill Edward Elgar Publishing, Cheltenham, UK. Langford, D. and Male, S. 2001. Strategic Management in Construction, Blackwell Science, Oxford. Lansley, P., Quince, T. and Lea, E. 1979. Flexibility and Efficiency in Construction Management, Final Report. Building Industry Group, Ashridge Management Collage, Amersham, Bucks. Momaya, K. 2004. Competitiveness of Firms: Review of Theory, Frameworks, and Models. Singapore Management Review, Volume 26, No 1, 45–60.

Ework and ebusiness in architecture, engineering and construction

1002

Momaya, K. and Selby, K. 1998. International competitiveness of the Canadian construction industry: a comparison with Japan and the United States. Canadian Journal of Civil Engineering, 25, 640–52. Ofori, G. 2003. Frameworks for Analyzing International Construction. Construction Management and Economics, (June 2003) 21, 379–91. Oz, O. 2001. Sources of competitive advantage of Turkish construction companies in international markets. Construction Management and Economics, 19, 135–44. Pheng, L.S. and Hongbin, J. 2004. Estimation of international construction performance: analysis at the country level. J of Construction Management and Economics, (March 2004) 22, 277–89. Porter, M.E. 1980. Competitive Strategy: Techniques for analyzing industries and competitors. The Free Press, NewYork. Porter, M.E. 1985. Competitive Advantage: Creating and Sustaining Superior Performance. The Free Press, NewYork. Porter, M.E. 1986. Competition in Global Industries: A Conceptual Framework. Harvard Business School Press, Boston, 1986. Porter, M.E. 1990. The Competitive Advantage of Nations. The Free Press, New York. Rugman, A.M. and D’Cruz, R. 1993. The ‘double diamond’ model of international competitiveness: the Canadian experience. Management International Review, Special Issue 2, 17–39. Segev, E. and Gray, P. 1994. A manager’s guide to business unit strategic analysis. In Warzawski, A. and Navon, R. (eds), Strategic Planning in Construction: Proceedings of the A.J.Etkin International Seminar on Strategic Planning in Construction Companies, Haifa, Israel, 8–9 June, pp. 16–34. Seymour, H. 1987. The Multinational Construction Industry. Croom Helm, London. Shen, L.Y., Lu, W., Shen, Q. and Li, H. 2003. A computeraided decision support system for assessing a contractor’s competitiveness. In: Automation in Construction 12 (5), Elsevier B.V., London, pp. 577–87. Sugimoto, F. 1990. Globalization of International Engineering and Construction Firms for Building Their Competitiveness. Unpublished PhD thesis, MIT. Toprakli, A.Y. 2004. Competitiveness in Construction Industry. Unpublished Master thesis, Istanbul Technical University. The World competitiveness yearbook. Lausanne; IMD Geneva: The World Economic Forum, 2003. Yates, J.K., Mukherjee, S. and Njos, S. 1991. Anatomy of Construction Industry Competition in the Year 2000. Source Document 64, Construction Industry Institute, Austin, TX.

Seismic risk and environmental management

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) ©2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Analyses of Izmit earthquake by means of remotely sensed data: a case study, Yalova city S.Kaya, F.Bektas, C.Goksel & E.Saroglu ITU Civil Engineering Faculty, Remote Sensing Division, Maslak-Istanbul ABSTRACT: On 17 August 1999 at 3:02 a.m. local time, the Izmit earthquake occurred on the North Anatolian Fault Zone (NAFZ) in the northwest Turkey. The surface rupture caused by the 1999 earthquake (Mw: 7.4) comprised four segments: the Gölcük, Izmit-Sapanca and Arifiye-Akyazi segments in the west (about 90km long) and the Gölyaka segment in the east (about 30 km long). The death toll in city centres was 15,851 and reported injuries 43,953 in greater urban areas the death toll was approximately 18,000 in total and reported injuries approximately 48,000. In this study, SPOT HRV (XI and Pan) images obtained before and after the earthquake were used to estimate the area of collapse buildings in Yalova city. The pre-earthquake and post-earthquake images were geometrically corrected and classified separately. Image differences between on 06 June 1993 and 9 September 1999 SPOT HRV Pan images were used to determine changes due to earthquake damage. In addition to this, urban spatial growth of Yalova city analyzed using SPOT HRV images between 1993 and 1999. Results, which were obtained by processing satellite sensor images, compared with government office and ground data.

1 INTRODUCTION The North Anatolian Fault Zone (NAFZ) is one of the most important active strike-slip faults in the world and the most important active fault in Turkey. During the 20th century, many destructive earthquakes occurred along this fault resulting in the collapse of 450,000 buildings and the death of over 80,000 people. In this period twenty-five destructive earthquakes (M>6.5) occurred and 7 of these earthquakes originated in the Marmara Sea region (Barka and Nalbant 1998). Between 1939 and 1967, six large fault ruptures formed a westward-migrating sequence of events along a 900-km-long near continuous portion of the NAFZ (Barka 1996). According to recent studies, most of the historical earthquakes in the Marmara sea region occurred on the northern strand of the NAFZ (Ambraseys and Finkel 1991, Barka 1991). Izmit (Kocaeli) earthquake occurred on the NAFZ in the northwestern part of Turkey. The earthquake started at the west, lasted for 12 seconds, paused for 18 seconds and was followed by rupture in the east for 7 seconds. The maximum offset along the surface break was measured near Arifiye, east of

Analyses of Izmit earthquake by means of remotely sensed data

1005

Sapanca (between Arifiye and Adapazari), where the fault displaced a road horizontally by about 5 m. This earthquake caused heavy damage in a density populated and industrialised region. Some cities affected were Izmit, Adapazari, Yalova, Golcuk, Istanbul, Bolu. The earthquake’s epicentre was located at latitude 41.8° and longitude 29.9°. The heaviest damaged area was around the Gulf of Izmit and the city of Yalova. The dead and injured located approximately 18,000 and 48,000 respectively in city centres (Barka, 1999). The distribution of those who died in city centres was: Golciik (5,025), Izmit (also known as Kocaeli) (4,093), Adapazan (also known as Sakarya) (2,629), Yalova (2,502), Istanbul (981), Bolu (264), Bursa (268), Eskişehir (86), Zonguldak (3) (Sahin and Tari, 2000). Monitoring and mapping change detection of urban area with time were the main objectives of remote sensing study. In addition to this, satellite sensor images can be used for many different application, such as land cover change (Yang 2002, Foody and Boyd 1999, Kaya and Curran 2003), mapping of earthquake damage (Lin et al. 2002, Fu and Lin 2003), earthquake displacement (Massonet et al. 1993), volcano deformation (Massonet et al. 1995), glacier dynamics (Mohr et al. 1998). Also land subsidence monitoring can be evaluated by means of differential synthetic aperture radar (SAR) interferometry (Strozzi et al. 2000, Strozzi et al. 2001). More specifically SPOT HRV data have been applied successfully to the assessment of earthquake damage due to the 1999 event in Golcuk (Turker and San 2003, Kaya et al. 2003, Kaya et al. 2004). Remote sensing techniques provide a rapid and powerful tool to detect natural disasters in the remote, inaccessible and large areas.

Figure 1. Ground photographs of the earthquake (http://www.yalova.gov.tr/).

Ework and ebusiness in architecture, engineering and construction

1006

The main objectives in this study are (i) to examine land cover change in Yalova city between 1993 and 1999 using SPOT HRV data (ii) to determine heavy damaged areas in 1999 earthquake using these data (iii) to investigate the utilization of SPOT HRV data for determination of earthquake damages in urban area. 2 METHODOLOGY 2.1 Study area (Yalova city) Yalova city is located in the northwest of Turkey and southeast of the Marmara Sea. Its geographic boundaries are between 39° and 40° S in latitude and between 29° and 31° E in longitude. The area of the region is approximately 839 km2. According to census data taken from State Institute of Statistics (SIS), the population of the city centre was 87032 in 1990, and 98.661 in 2000. Increase in rate of population in the year of 2000 was 12.54% in city centre. Yalova has become city since 6 June 1996. Altitude of Yalova is 2m and the highest point of the city is 926m. 17 August 1999 earthquake caused considerable damage and deaths in Yalova city. The number of collapsed and heavy damaged buildings in the city centre was 517 and 7606 respectively. The death toll in the city centre was 1449 and reported injuries were 2543. Approximately 50% of buildings and a great percent of the local roads were damaged in 17 August earthquake. Postearthquake ground photographs were shown in f igure 1. After the earthquake immigration has occurred to other cities. The earthquake caused to damage to agriculture such as 30% of the flower and plant greenhouses were destroyed. In order to mitigate effects of the earthquake damages, 17777 tents were pitched up in a total of 10 different areas. 2.2 Classification The overall objective of classification is to automatically categorize all pixels in an image into land cover classes or themes (Lillesand and Kiefer, 2001). Image classification is the process used to produce thematic maps from imagery. Classification can be performed either supervised or unsupervised. For unsupervised classification, the analyst employs a computer algorithm that locates concentrations of feature vectors within a heterogeneous sample of pixels. These so-called clusters are then assumed to represent classes in the image and are used to calculate class signatures (Schowengerdt, 1997). In this study, an unsupervised classification algorithm called ISODATA clustering was used. 50 clusters were selected for ISODATA algorithm. After performing ISODATA clustering, these 50 clusters were merged and five classes (water, sand, urban, agricultural area and forest) were formed (Figure 2).

Analyses of Izmit earthquake by means of remotely sensed data

1007

Figure 2. Classified SPOT HRV images of 1993 and 1999.

3 RESULTS 3.1 Land cover/use change Yalova which is very important city for agricultural production also has been used as touristic purposes during the summer time for two decades. After becoming city on 6 June 1995, the population of the city has been increasing and this caused expansion of urban areas. In addition, in order to provide increasing accommodation demand, various kinds of structures were constructed and new housing complex were built. 1993 SPOT HRV XS and 1999 SPOT HRV XI data were classified in order to obtain land cover/use classes in the study region. Areal changes in land cover/use were determine using classification results. Classification results of 1993 SPOT HRV XS data showed that the areas of water, sand, urban, agricultural area and green area & forest were 3863.9ha, 18.9ha, 393.2 ha, 2519.2 ha and 2027.9 ha respectively. The results of classified post earthquake image illustrated that the areas of water, sand, urban, agricultural area and green area & forest were calculated as 3867.7ha, 19.2 ha, 487.6 ha, 2448.8 ha and 1999.8 ha, respectively (Table 1). According to these results significant changes had occurred in urban, agricultural, and green & forest categories. Especially, change in urban area was determined as 24%. On the other hand, change in agricultural area was found approximately—2.79% and change in green & forest area was found— 1.39%.

Table 1. Land cover changes between 1993–1999. Classes Water Sand area

Date 1993

Area (ha)

Date 1999

Area (ha)

3863.9

3867.7

18.9

19.2

Ework and ebusiness in architecture, engineering and construction

Urban area

1008

393.2

487.6

Agricultural area

2519.2

2448.8

Green area & forest

2027.9

1999.8

3.2 Determination of earthquake-induced heavy damage areas In order to delineate heavy damage areas, two methods were used. In the first method, 1999 SPOT Pan

Figure 3. Merged SPOT HRV Panchromatic and SPOT HRV XI image 1999. and XI images were merged using Brovey algorithm and visual interpretation of the new merged image was performed. In the second method, the difference image was produced by subtracting the pre- and post-earthquake images and heavy damage class was determined by applying level slicing algorithm to the difference image. Wald (2002) describes fusion as ‘a formal frame work in which are expressed means and tools for the alliance of data originating from different sources. It aims at obtaining information of greater quality; the exact definition of greater quality will depend upon application.’ SPOT HRV Panchromatic data which has better spatial resolution was merged with SPOT HRV XI which has better spectral resolution to discriminate characteristic features of Yalova city after the earthquake. The merged image is shown in figure 3.

Analyses of Izmit earthquake by means of remotely sensed data

1009

According to figure 3, A1, A2, and A3 are the unchanged urban areas in Yalova city after earthquake. B1 and B2 are prefabricated houses which were done to provide accommodation demand for after the earthquake. C1, C2 and C3 are the regions that debris were filled. D1, D2, D3, D4, D5, D6, D7, D8 and D9 regions which were located in the inner city, south and east of the study area demonstrate heavy damaged and collapsed buildings. Level slicing is an enhancement technique whereby the DNs distributed along the x axis of an image histogram are divided into a series of analyst-specified intervals or slices. It involves the grouping of image regions with similar DN (Lillesand and Kiefer). Examination of level sliced difference image demonstrated spectral mixtures between some land cover/use classes. Spectral mixture occurred between heavy damaged areas, new constructed prefabricated houses, earthquake induced ruin roads and debris field. Therefore, prefabricated houses, ruin roads and debris field were digitized from level sliced difference image to determine the area of heavy damaged buildings in figure 4. The area obtained by digitizing was subtracted from total changed area derived by level slicing and earthquake-induced heavy damaged area found 76, 47 ha. 3.3 Usability of SPOT HRV data Both panchromatic and multi spectral SPOT HRV data in conjunction with ground data were used in a variety of applications such as disaster management, risk analysis and regional catastrophes. SPOT HRV data with repetitive acquisition of the synoptic view images are used to provide immediate and rapid access to disastrous regions. The location and size of the regions which are severely affected in a disaster can be determined using SPOT HRV data. In the study, results obtained from processed image were compared with ground data obtained from www.koeri.boun.edu.tr/. The comparison results were

Figure 4. Superimposed image of level sliced difference image and digitized categories.

Ework and ebusiness in architecture, engineering and construction

1010

Figure 5. Ground data of the study area (http://www.koeri.boun.edu.tr/). consistent with each other. Ground data of study area acquired on 20 August 1999 is shown in figure 5. 4 CONCLUSIONS Remote sensing technology can be used to provide advance warning for specific hazardous events in the case of natural disasters, to monitor the area of concern or quickly evaluate the damage in order to support the decision-making process in the rescue operations. In this study, collapsed and heavy damaged buildings in the Yalova inner city affected by 1999 (Mw: 7.4) Izmit Earthquake were determined by means of SPOT HRV data. Land cover/use changes before and after earthquake were derived from classification of SPOT HRV XI and XS data. Moreover, heavy damaged areas in the inner city were obtained level sliced difference image of 1993 and 1999 SPOT Panchromatic data. Between the year of 1993 and 1999, urban areas increased 24%; also, the population of the inner city was increased from 87032 to 98661 between 1990 and 2000. However, the population of study area increases mainly at summer time. Rapidly changed areas in the Yalova were determined using panchromatic difference image. One disadvantage of the SPOT HRV data is spectral mixture problem. Heavy damage areas, debris areas and prefabricate houses have similar spectral reflectance; therefore, this caused obtaining similar digital numbers for these categories. The mixture problem in these categories was solved with digitization. As a result, heavy damage areas were found as 76.47 ha. SPOT HRV data were useful for regional scale disaster studies. However, SPOT HRV data has drawbacks while studying local scale disasters. High resolution satellite imagery in conjuction with field surveys should be used in order to investigate earthquake-induced damages in detail.

Analyses of Izmit earthquake by means of remotely sensed data

1011

REFERENCES Ambraseys, N.N. & Finkel, C.F. 1991. Long-term Seismicity of Istanbul and the Marmara Region, Engineering Seismology Earthquake Report, 91/8, Imperial College. Barka, A.A. & Nalbant, S. 1998. 1700 ve sonrasi Marmara depremlerinin modellenmesi, Aktif Tektonik Araştirma Grubu Birinci Toplantısı, İTÜ Avrasya Yerbilimleri Enstitüsü, İstanbul. Barka, A.A. 1991. İstanbulun depremselliğini oluşturan tektonik yapılar ve İstanbul için bir mikro bölgelendirme Grubu Birinci Toplantisi, İTÜ Avrasya Yerbilimleri Enstitüsü, İstanbul. Barka, A.A. 1991. İstanbulun depremselliğini oluşturan tektonik yapilar ve İstanbul için bir mikro bölgelendirme denemesi, Istanbul ve Deprem Sempozyumu, İnşaat Mühendisleri Odasi, Istanbul, 78–98. Barka, A.A. 1996. Slip distribution along the North Anatolian Fault associated with the large earthquakes of the Period 1939 to 1967, Bulletin of the Seismology Society of America 86:1238– 1254. Barka, A.A. 1999. The 17 August 1999 Izmit earthquake. Science 285:1858–1859. Barka, A.A. & Reilinger, R. 1997. Active tectonic of the Eastern Mediterranean Region: Deduced from GPS, Neotectonic and Seismicity Data, Annali di Geofisia XL: 587–610. Foody, G. & Boyd, D.S. 1999. Detection of partial land cover change associated with the migration of inner-class transitional zones, International Journal of Remote Sensing 20:2723–2740. Fu, B. & Lin, A. 2003. Spatial distribution of the surface rupture zone associated with the 2001 Ms 8.1 Central Kunlun earthquake, northern Tibet, revealed by satellite remote sensing data, International Journal of Remote Sensing 24:2191–2198. Kandilli Rasathanesi, http://www.koeri.boun.edu.tr/, 10 June 2004. Kaya, S. & Curran, P.J. 2003. Monitoring urban growth on the European side of the Istanbul metropolitan area, P.Aplin & P.M.Mather (editors), Proceedings of Remote Sensing and Photogrammetry Society 2003, Scales and Dynamics in Observing the Environment, 10–12 September. Nottingham: UK, (on CD ROM). Kaya, S. Llewellgn, G. & Curran, P.J. 2004. Displaying earthquake damage and urban area using vegetation impervious soil model and remotely sensed data, ISPRS XXth Congress, 12–23 July, Istanbul, Turkey (Submitted). Kaya, S. Muftuoglu, O. & Tuysuz, O. 2004. Tracing the geometry of an active fault using remote sensing and digital elevation model: Ganos segment, North Anatolian Fault zone, Turkey, International Journal of Remote Sensing (submitted). Lillesand, T.M. & Kiefer, R.W. 2000. Remote Sensing and Image Interpretation. New York: John Wiley and Sons. Lin, A. Fu, B. Guo, J. Zeng, Q. Dang, G. He, W. & Zhao, Y. 2002. Co-seismic strike-slip and rupture length produced by the 2001 Ms 8.1 Central Kunlun earthquake, Science 296:2015– 2017. Massonet, D. Briole, P. & Arnaud, A. 1995. Deflation of the Mount Etna monitored by spaceborne radar interferometry, Nature 375:567–570. Massonet, D. Rossi, M. Carmona, F. Adragna, F. Peltzer, G. Feigl, K. & Rabaute, T. 1993. The displacement field of the Landers earthquake mapped by SAR interferometry, Nature 364:138– 142. Mohr, J.J. Reeh, N. & Madsen, S.N. 1998. Three dimensional glacial flow and surface elevation measured with radar interferometry, Nature 391:273–276. Sahin, M. & Tari, E. 2000. The August 17 Kocaeli and the November 12 Duzce earthquakes in Turkey. Earth Planets Space 52:753–757. Schowengerdt, R.A. 1997. Remote sensing: models and methods for image processing, Academic Press, San Diego.

Ework and ebusiness in architecture, engineering and construction

1012

Strozzi, T. Dammert, P. Wegmuller, U. Martinez, J.M. Askne, J. Beaudoin, A. & Hallikainen M. 2000. Land use mapping with ERS SAR interferometry, IEEE Transaction on Geoscience and Remote Sensing 38:766–775. Strozzi, T. Wegmuller, U. Tosi, L. Bitelli, G. & Spreckels, V. 2001. Land subsidence monitoring with differential SAR interferometry, Photogrammetric Engineering and Remote Sensing 61:1261–1270. Turker, M. & San, B.T. 2003. SPOT HRV data analysis for detecting earthquake-induced changes in Izmit, Turkey, International Journal of Remote Sensing 24:2439–2450. Wald Lucien., 2002. Data Fusion: Definitions and Architectures. Les Presses de 1’Ecole des Mines, Paris. Yalova Valiligi, http://www.yalova.gov.tr/, 10 June 2004. Yang, X. 2002. Satellite monitoring of urban spatial growth in the Atlanta metropolitan area, Photogrammetric Engineering and Remote Sensing 68:725–734.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) ©2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Do phased Environmental Management Systems actually benefit SMEs? L.L.Hopkinson Welsh School of Architecture, Cardiff University, Cardiff, United Kingdom C.Snow Mandix*, Cardiff, UnitedKingdom ABSTRACT: Many larger businesses have seen benefits from implementing Environmental Management Systems. These larger businesses have put pressure onto their smaller suppliers to consider similar systems, which for a Small to Medium Sized Enterprise (SME) can prove inappropriate. However, the arrival of new phased approaches hopes to bridge the gap between a full EMS and nothing at all, to provide business benefits to SMEs. But do these systems actually provide any benefits? This study uses case studies and follows the implementation of phased approach EMSs (BS 8555, Green Dragon, and Easy Access for Environmental Management). The case studies show what benefits are seen by adopting environmental management, even to a low level, and highlights the benefits of phased approaches to SMEs.

1 BACKGROUND An Environmental Management System (EMS) is a management tool for understanding, identifying and controlling environmental impacts of a businesses activities, products and services. The first formalized approach was introduced in 1992 with the introduction of British Standard BS 7750 (ENDS 1992). This was then followed by the introduction of the European Eco-Management and Audit Scheme (EMAS), which was adopted within the UK in 1995 (ENDS 1995). Following the arrival of EMAS, the European Standards body (CEN) was provided with a briefing to devise an environmental management standard that offered firms a practical alternative to registration under EMAS (ENDS 1995). The resulting draft was formally issued in 1996 and called ISO 14001. This International Standard replaced BS 7750, which was formally withdrawn in 1997. Following the publication of ISO 14001, an entire ‘family’ of ISO 14000 standards were published, each relating to EMS and related environmental management tools (ISO 1998). Uptake of these formalized systems has gathered pace in the years following their introduction. By 1999, nearly 3,000 sites across the EC had registered to under EMAS, but more than three times as many had been certified under ISO 14001 (ENDS 2000).

Ework and ebusiness in architecture, engineering and construction

1014

For many companies, however, there can be problems with implementing a system, despite all the potential benefits (such as cost savings, increased awareness and compliance with legislation). Major problem areas include a lack of senior level commitment to undertaking such work, a struggle to make all employees aware of the implications of the EMS and resistance to change in working practices (Institute of Environmental Management 1998). Within Small and Medium sized Enterprises (SMEs), there is also the problem of limited financial, technical and manpower capabilities to implement adequate enviromnental measures (Chiu et al 1999), as well as external barriers including difficulties in obtaining useful and consistent advice, the high costs of certification to a standard and the lack of drivers to obtain a system (Hillary 1999). SMEs find formal systems such as ISO 14001 too rigid, and as such prefer a system that can be broken down into elements to suit their individual needs (Hopkinson & Jones 2002). For these reasons, phased approaches were suggested. A phased approach of implementation was described in 1995 (Heijdra 1995). Here, the EMS was broken down into six steps to show a simple project approach to implementing such a system. Another approach was the Business Environment Association (BEA) ‘Environmental Healthcheck’, which provided 5 levels *Mandix is a private management consultancy company based in Cardiff.

of accreditation, with certificates provided for each completed level. Despite winning funding from the European ADAPT programme, this initiative folded in 1999. The ISO TC 207 working party (subcommittee 1) did consider adapting ISO 14001 to encompass special issues of SMEs, but decided that no new standards of other documents would be issued. Following this, in 2000, Project Acorn was launched by the British Standards Institution. This project provided a five level approach to implementing an EMS compatible with ISO 14001, with a sixth level providing compatibility with EMAS (ENDS 2001). This project resulted in the creation of the first phased Environmental Management Standard BS 8555, launched in April 2003. On a regional level, the Welsh Green Dragon standard was launched in 2002, again providing a five level approach to implementing an EMS compatible with ISO 14001. With both of these initiatives, SMEs can obtain certificates to show achievement of a particular level of environmental management. A recent report by the European Commission’s Enterprise Directorate indicated that few SMEs have adopted EMSs. This report recommended the promotion of SMEfriendly implementation of EMS, especially using staged approaches (European Commission 2004). Phased EMS approaches have therefore been designed with SMEs in mind, and the European Commission recommends these approaches for encouraging uptake of EMS. However, there has not yet been any reported research on the effectiveness of these systems within SMEs.

Do phased Environmental Management Systems actually benefit SMEs?

1015

2 PROJECT BACKGROUND AND METHODOLOGY 2.1 Project background The work presented in this paper is from a two-year European Regional Development Funded project, based in a South Wales Unitary Authority. The work is carried out by Cardiff University in partnership with Mandix. The aim is to assist 40 SME companies in the study area to implement a phased EMS, based upon their specific needs. The project assists in working towards the Welsh assembly Government’s target of 500 companies implementing an EMS (Welsh Assembly Government 2002), and recommends the most appropriate EMS to the company concerned; BS 8555 if the company predominantly has clients within the UK; Green Dragon if the company only works with local Welsh clients or ISO 14001 if the company works internationally. The phased approaches used are based upon formalized systems; hence the methodology is already set. Both BS 8555 and Green Dragon are similar in methodology and are based upon ISO 14001 for ease of upgrade. 2.2 Project methodology The project was designed to run as simply as possible, as follows: • Company recruitment • Initial survey to identify needs • Recommendation by project team of appropriate phased EMS and level • Assistance provided to achieve recommendation • Exit survey at end of project to highlight benefits of the work. Participation in the project was voluntary; therefore the project team could not predict which industrial sectors would participate. To date, the project has enrolled companies from the tourism, construction, manufacturing and commercial sectors of industry. 3 RESULTS It is noted that the results obtained are based upon the project’s first year of operation. Full project results will be published after completion of the project in 2005. 3.1 Initial survey results All project participants were asked to complete an initial survey. This initial survey questioned the company’s motivation for participation, current levels of knowledge on environmental management issues within the company, location of major clients and what initiatives the company has already undertaken. This allowed the project team to recommend an appropriate system and level (based upon information provided upon

Ework and ebusiness in architecture, engineering and construction

1016

location of major clients), as well as assess the current level of knowledge within the company of EMS. The results presented are based on initial surveys administered to 25 companies during the first year of the project, and represents responses to perceived benefits of implementing an EMS. These surveys were administered to the key contact point established within the company, and were therefore highly placed personnel (i.e. a Managing Director, Proprietor or Quality Manager). 3.1.1 Reasons for implementing the system Participants were questioned on their motivation for implementing an EMS against seven key criteria, based upon experience from previous work (Hopkinson & Jones 2002). Table 1 lists the responses in terms of percentage responses for each criterion. The results of this question show that the SMEs involved were highly motivated towards improving business management, then achieving legal compliance and improving their marketing through such a system. To a lesser extent, the SMEs were not as concerned with improving relations with regulators as many of the companies enrolled reported that they did not have much contact with regulators.

Table 1. Responses to motivation for implementing an EMS. Criteria

Percentage

Management issues To increase efficiency

84

To increase profits and reduce costs

76

To increase benefits to employees

72

Marketing issues To enhance public image

80

To increase benefits to customers

76

Legal issues To improve compliance with legislation

80

To improve relations with regulators

64

Table 2. Percentage responses of the top three ranked criteria. Percentage for rank Criteria

1

2

3

Customer pressure

4

4

0

Marketing reasons

16

4

4

Do phased Environmental Management Systems actually benefit SMEs?

Cost cutting reasons: general

1017

8

4

4

20

12

12

Material & inventory reduction

8

0

12

Setting targets

8

4

0

Job creation

0

0

0

Reducing energy usage

4

20

8

Reducing water usage

4

4

12

Revealing opportunities

8

16

4

Management efficiency

4

4

0

16

0

12

Pollution prevention

Ensuring legal compliance

3.1.2 What enrolled companies hoped to achieve Participants were asked to give their reasons for implementing an EMS through the project by indicating what they hoped to achieve through the process. Twelve criteria were listed (again based upon previous experience); respondents were asked to rank their top 3 criteria in terms of importance to them. On occasions, some respondents identified 5 key criteria, and ranked these accordingly. Table 2 lists the percentage responses received in terms of the top three ranked criteria. Compared to the results above, there is a slight deviance in issues that motivate companies to participate and what they would hope to achieve from such work. The prevention of pollution is ranked highest on the agenda for SMEs, along with ensuring legal compliance and gaining a marketing edge over competitors. Ranked second highest is the reduction of energy use (an issue which can save SMEs money as well as provide environmental benefits) and revealing other opportunities (entrance into new markets or other benefits). Ranked joint third includes issues such as material and inventory reduction (reducing the amount and variety of raw materials and components that are stored for future use by the company) and reducing water usage (again, an issue which can save money as well as provide environmental benefit), as well as pollution prevention and legal compliance. 3.2 Benefits from implementation These initial results provided the project team with a clear indication of what individual SMEs wished to achieve through the implementation of their phased EMS. An assessment of the work in progress was carried out, using details from initial surveys and baseline reviews, as well as face-to-face assessments from the enrolled companies, carried out on a regular monthly basis. This assessment shows that the following ten key benefits were identified:

Ework and ebusiness in architecture, engineering and construction

1018

Increased awareness—all participants agreed that, by undertaking such a process, they were made more aware of what environmental impacts their processes/ activities/services made. Only by increasing this awareness can any environmental improvement hope to be sustained within a company. Legal compliance—the large majority of the SMEs participating recognized that they were not aware of environmental legal obligations, and therefore agreed that even a basic EMS process assisted with this respect. All companies participating will be creating a legal register. None of the participants reported any regulatory pressure towards compliance e.g. regular visits by the Environment Agency or other enforcement bodies. Reduction of waste costs through the linkage to free recycling schemes—96% of all participants were able to make use of free of charge recycling schemes e.g. for paper waste, used inkjet and toner cartridges and some glass waste, therefore reducing the amounts of waste sent to landfill and therefore paid for. With the Landfill Tax in the UK set to increase, this aspect can ensure cost savings are realized year after year. Production of electronic tools to reduce paper use dependency—4 companies are set to trade electronically through the creation of company websites and use of email, to help reduce dependency on paper use. This aspect also assisted towards competitiveness within the individual business sector. Wherever possible, archiving and obtaining technical information by electronic means was also suggested, again to reduce paper use dependency and physical storage space. Reduction in energy use through the simplest of means—all participants reported awareness of how to reduce energy use by advising on simple measures such as the purchase of energy efficient alternatives (e.g. lighting, computing, insulation and other relevant equipment). Reduction in water use, even for low water users-all participants also reported awareness of how to reduce water usage, even those who were not heavy users of water for business purposes. This benefit will be reflected more in reduction of costs (or potential reduction in service charges); although all participants did also understand the environmental benefits (especially as drier weather in the study area was more prevalent). Marketing and tendering opportunities—of most benefit to those participants whose major clients were in the public sector. 24% reported this benefit, especially as the Welsh Assembly Government has a Statutory Duty to make a scheme for Sustainable Development, which affects their and other bodies’ procurement practices. Improvement in house keeping activities to reduce degradation of usable raw materials—all participants reported improvements in housekeeping activities, by being advised on what to improve. Many had found that simply moving certain items away from water ingress or other potential weather conditions reduced the amount of spoilage seen onsite. Signposting to academic experts—two companies were able to link to academic experts in order to refine processes and make improvements. Introduction of alternative technologies to make use of problem wastes—one company was made aware of waste-to-energy schemes, which provided additional benefits of ensuring waste was dealt with in a legally compliant manner, and the provision of space heating in a factory where none existed.

Do phased Environmental Management Systems actually benefit SMEs?

1019

4 CONCLUSIONS AND RECOMMENDATIONS From the results seen to date, this project shows that implementing a phased EMS can provide a variety of business benefits through environmental improvement to individual SMEs. The phased approach is better suited to SMEs as they are able to work towards achieving actual improvements, without the cumbersome documentation required in a full ISO system. These results are based upon participants who agreed voluntarily to take part in the project—it can therefore be argued that these companies could already foresee some business benefits in making environmental improvements. However, only one company indicated that there was any external pressure on them to implement such a system—in this case, it was group management pressure. None of the other companies indicated any external pressure (group or regulatory) forcing them to implement such a system. There was also little reported customer pressure towards implementing such a system, although 5 companies did indicate that questions relating to company environmental policy had been asked of them during tendering processes. The results clearly show that the majority of the participants were most interested in increasing their efficiency as a business, and upholding their legal and environmental responsibilities. The voluntary participation highlights that SMEs are able to make their business decisions based upon awareness of the issues. Further work in this area is recommended. Effectiveness of phased EMSs in the longterm has not been identified. It is therefore important to identify if companies keep the initiative in operation as integral part of their business. The second year of this project hopes to look into this aspect in further detail. SMEs need to be made aware of the benefits of such an approach, especially in the situation where there is neither regulatory ‘push’ nor customer ‘pull’ to force change. A possible initiative to assist in this aspect could be awareness raising through the Government. For example, the Welsh Assembly Government has set targets for this type of work; investigation into if this target has been achieved is required to assess the effectiveness of such initiatives. REFERENCES Chiu, S., Huang, J.H., Lin, C., Tang, Y., Chon, W. & Su, S.C. 1999. Applications of a corporate synergy system to promote cleaner production in small and medium enterprises. Journal of Cleaner Production7(5)p351–358 ENDS. 1992. BS7750 sets environmental standardization bandwagon rolling. ENDS Report (207) p20–21 ENDS. 1995. Weak ISO draft threatens Europe’s environmental management standards. ENDS Report (240) p25–27 ENDS. 1995. EMAS slow off the starting blocks. ENDS Report (243) p6–7 ENDS. 2000. Japan & UK lead growth in ISO 14001 uptake. ENDS Report (301) p7–8 ENDS. 2001. Late spring for DTI’s Acorn supply chain project for smaller firms. ENDS Report (320) p33 European Commission. 2004. Public policy initiatives to promote the uptake of Environmental Management Systems in Small & Medium sized Enterprises: Final report of the Best Project Expert Group. Brussels, European Commission

Ework and ebusiness in architecture, engineering and construction

1020

Heijdra, G.1995. Implementing Environmental Management Systems: A project management method. ERP Environmental 1995 Eco-Management and Auditing Conference proceedings, University of Leeds, UK, July 1995, p117–126 Hillary, R. 1999. Evaluation of study reports on the barriers, opportunities and drivers for small and medium-sized enterprises in the adoption of Environmental Management Systems. DTI, London, p1–58 Hopkinson, L. & Jones, P.2002. Innovating ISO 14001 to suit the needs of an SME: A case study. Stimulating Excellence in Small and Medium Enterprises (SMESME) 2002 conf. proc., Essex, UK, May 2002, p166–172 IEM. 1998. Survey 1998: ISO 14001 and EMAS. Institute of Environmental Management Journal 5(4)p1–36 International Organization for Standardization. 1998. ISO 14000–Meet the family! Geneva. ISO. Welsh Assembly Government. 2002. Wise about Waste: The National Strategy for Wales Part One. Wales p58–59

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) ©2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Software based knowledge integration for seismic risk management R.Pellegrini Enel Hydro—Ismes, Seriate (BG), Italy P.Salvaneschi University of Bergamo, Faculty of Engineering ABSTRACT: The paper describes the knowledge integration approaches followed during the development of the software package SEISMOCARE. The tool (the result of the evolution of a number of projects funded by E.U. and Italian National Research Bodies) supports users of different technical background active in seismic risk analysis and strengthening strategy definition and requires the integration of knowledge sources coming from various disciplines. The following knowledge integration issues are discussed: types of knowledge; how the knowledge integration requirement affected the software engineering process; technical solutions at specification, design and implementation level. The key solutions are the specification of an explicit knowledge model, a two-layer architecture (knowledge model implementation and functions exploiting the model capabilities) and the use of a GIS as implementation environment.

1 INTRODUCTION The evaluation of seismic vulnerability and seismic risk reduction by means of retrofitting of existing building heritage is a significant problem in many countries. Suitable software tools may support the evaluation process, providing environments for data and models integration and scenarios simulation. The development of this type of tools requires diverse types of knowledge, coming from seismology, geotechnical engineering, seismic engineering and risk management. From the information technology point of view, a supporting tool requires the integration of databases and computational components in a GIS based environment. The paper describes the capabilities of SEISMOCARE, a software package developed to support users of different technical background (e.g. experts as well as civil protection authorities), active in seismic risk analysis and strengthening strategy definition. The tool is the evolution of a number of projects funded by E.U. and Italian National Research Bodies. Chapter 2 provides a general overview of the system capabilities. The remaining chapters discuss the knowledge integration issues: what knowledge was integrated; how the knowledge integration requirement and the evolutionary approach of the system

Ework and ebusiness in architecture, engineering and construction

1022

development affected the software engineering process; how the knowledge was codified and how was the unification of the knowledge accomplished through suitable architectural and implementation choices. 2 SYSTEM OVERVIEW The objective of the system development is to produce a software package for reliable predictions of losses due to earthquakes in a city or region. The software package is essentially a simulator with which the effects of damaging earthquakes in an urban area may be simulated and the losses estimated. It can be used to provide information useful for formulating seismic risk mitigation policies, planning and taking measures, effective both in the long term as well as for emergency response. The forecasted final users are people directly involved in the result of software simulations at various levels of expertise, depending on the type of simulation (adopted models, computing parameters and interpretation of the results). The basic planned features of the system allow its use even by persons not highly specialized. The simulator is composed by the following three basic inter-linked sets of modules: – The seismic hazard set – The vulnerability set – The loss estimation set Each set is a toolbox, including various types of data and models, which may be used according to specific goals and constraints (e.g. available data, costs…). A number of functions exploit the simulation capabilities linking together the basic modules for defined purposes (global simulation, emergency preparedness support, planning support). Through them, the user can explore possible scenarios following the earthquake and simulate the effects of actions on the urban nucleus. The person/machine interface supports: – The detailed control of the simulation step by step (seismic source definition, propagation to the bedrock, site effects modeling, damage computation, losses computation); – A recording functions allowing to execute a sequence of simulations steps in the recording mode, to generate a scenario simulation to be re-executed; – The ability to re-use specific predefined scenarios (e.g. for civil protection support) that were generated through the recording facility; – Special functions to exploit the scenarios for a specific use. A comprehensive set of functions allows supporting the planning activities through the simulation of strengthening actions for seismic reinforcement of buildings. Another set of functions allows supporting emergency preparedness for civil protection. The Seismic Hazard component is used to assist in selecting the scenario earthquake(s) and to generate expected motion parameters at a grid of points on the surface, covering the area of interest for the scenario quake. The module includes the following components:

Software based knowledge integration for seismic risk management

1023

– SEISMIC INPUT. It includes the seismicity data (earthquake history catalogues and related parameters (date, magnitude, location, depth, etc) and information related to active faults (type of fault if known, length, activity rate, maximum possible event, etc) as well as the attenuation models estimating the seismic input at bedrock. The result of the computation is the seismic input in terms of bedrock acceleration and/or intensities at the site under investigation (seismic hazard or seismicity measures). The computation of the seismic input at the bedrock may be done in two ways by direct specification of a scenario PGA or by specification of a scenario earthquake(s) at any of the specified potential seismic sources and a subsequent attenuation to the sites of interest. – SITE EFFECTS. This component computes the effects of bedrock motion on the soil deposits at the area of interest and provides estimates of the ground motion at the surface. The vulnerability assessment component assists in defining the elements at risk and producing the vulnerability and damage measures, required for estimating losses. The module includes the following components: – INVENTORY: each catalogued structural object is described through a suitable classification (General buildings, special buildings with high concentration of people, critical facilities, utility buildings, lifelines). For each classified structure, a set of data is included (e.g. exposure occupation density). Each object has to be geo-referenced. – VULNERABILITY: it includes data and models at various levels of detail (e.g. GNDT1 model adapted to compute vulnerability and GNDT2 model) to compute the vulnerability of buildings (masonry and reinforced concrete), lifelines and special structures. The component allows managing all the data coming from the surveys, which are needed by the vulnerability models. It is possible to run the vulnerability models associated to each structural object and use the data to compute the vulnerability indexes. Note that the systems may host models at various level of accuracy, according with the available data. This feature allows the use of the software in real situations according with different possible survey strategies. Moreover, it is allowed to store data about possible strengthening techniques. The system manages rules that modify the vulnerability indexes according to the application of each strengthening technique. In such a way, it is possible to simulate the effects of a strengthening strategy on an urban nucleus. – DAMAGE: it includes data, models and functions for estimating damage as follows: – Direct estimation of building damage without prior computation of vulnerabilities (e.g. by means of the PSI model); – Estimation of damage from seismic input and vulnerability indexes (computed through vulnerability models); – Conversion of damage indexes produced by various models or methods into a uniform damage scale so that the user can compare them. Moreover it is included the module INTENSITY MAPS which is able to manage the computation of damage following a process which takes as input an intensity map and transforms it through amplification at bedrock models and soil effect models. This is

Ework and ebusiness in architecture, engineering and construction

1024

another way of simulate the structural damage (with no use of acceleration information and Vulnerability/ Damage models). The loss estimation component includes functions related to the management of data that are needed to activate losses models and compute losses through losses models. It also includes types of models, which may take as input the data of damage, intensity and seismic input described using accelerations. The loss estimation module quantifies the loss estimates in terms of: – Built environment damage; – Human losses; – Displaced people; – Direct and indirect economic losses. The software package also includes functions needed to manage the simulator and exploit it. This kind of functions may be added to the simulator without changing the structure of the simulator itself. This is the way to specialise the product and improve its value for the users. An example is the module for EMERGENCY PREPAREDNESS SUPPORT, which provides specific functions useful to support the preparedness to deal with emergencies. It may produce additional maps with the following information: – Expected number of safe buildings; – Expected number of safe buildings appropriate for temporary shelters; – Post-earthquake conditions of critical facilities; – Post earthquake conditions of lifelines; – Accessibility/evacuation routes of the urban system (related both to urban and suburban roads and their connection points); – Gathering areas/structures and aid services (locations, availability and accessibility for present conditions). Another example is a module able to use the simulator to generate global scenarios for PLANNING and LOSS REDUCTION SUPPORT. It provides specific functions useful to support the urban planning and loss reduction activities, allowing modifying the existing situation of the urban area and simulating the earthquake effects in the new scenario. It may produce additional maps with the following information: – Effects on the urban area after extensive buildings strengthening actions; – Effects on the urban area in case of removal of dangerous structures. – Simulated scenarios in case of new expansions of the urban area. The system is based on a set of data layers stored into a Geographic Information System (GIS) software needed to give information to the user about the simulation theatre (e.g. administrative borders, active faults, lakes, main roads, motorways, railways, lifelines, seismo-genetic zones). This set of layers and the GIS capabilities act as integration environment. They allow hosting the specific sets of data required by the simulator. The GIS software act also as environment for the person/ machine interface.

Software based knowledge integration for seismic risk management

1025

3 TYPES OF KNOWLEDGE The development of the system requires the cooperation of experts, coming from diverse disciplines: seismology, geotechnical engineering, seismic engineering, and risk analysis. Each discipline makes available a large amount of knowledge. Knowledge modules (data and models) have to be selected to cooperate according with the aims of the system (the forecasted users). The knowledge is embodied into three diverse containers: data, models and combination rules. Examples of data are an earthquake catalogue and the related parameters (date, magnitude, location, depth, etc) or a set of data coming from a seismic vulnerability survey of an urban nucleus or again a map of roads at regional scale. A set of seismic vulnerability/damage models may be a models example. The set may include models at various levels of detail to compute the vulnerability and the damage of buildings (masonry and reinforced concrete), lifelines and special structures. Another example is a set of acceleration propagation/ attenuation models to propagate the effects of diverse types of seismic sources. Combination rules describe input/output relations and constraints. The overall functionality of the system is obtained linking together (through input/output relations) a number of data and models. The simulation of the effects of an earthquake starts from a seismic source (e.g. an active fault), propagates through a geographical region, takes into account the contribution of the local soil under the urban nucleus and finally cause the damage status of each building. Many modules may be available to solve a specific simulation step for a defined purpose. The system hosts models at various level of accuracy, according with the available data. E.g., the building damage may be evaluated through a simple damage model based on a building classification. More detailed models are based on data coming from a standard street surveys or a deeper evaluation of the structural properties of the building. The availability of diverse possible chains of data and models requires the definition of constraints. E.g. a specific chain of data and models may be suitable for the simulation of the earthquake effects at regional scale and not at urban nucleus scale and may be appropriate for a shallow earthquake seismic source. The constraints may arise not only from technical problems (the best solution for a given simulation problem) but also from economical ones. E.g. the simulation goal could be a first level, low cost damage ranking of an urban nucleus, given the data coming from a street survey. 4 KNOWLEDGE INTEGRATION AND SOFTWARE ENGINEERING PROCESS What does it mean “knowledge integration”? Are there specific requirements to be satisfied to integrate the knowledge? The first requirement, at the beginning of the project, in the specification phase, is to define the goals for the integration. The integration is goal oriented and depends on the intended uses of the system. A second requirement, during the specification phase, is to develop an accurate model of the interesting set of knowledge modules and their relationships.

Ework and ebusiness in architecture, engineering and construction

1026

The model is the core of the specification. It is used as a co-operation blackboard between the experts of the various areas. Each expert should understand the linguistic tool used to express it. Finally, the knowledge integration issue means to design and implement a system where data, models ad constraints may be chained together to compose in a safe and easy way a useful procedure for a defined goal. The conclusion is that we have to integrate the knowledge through a software engineering process and we have to manage the integration issue during each phase of the process. In the following, we describe how the requirement has been considered during the specification and the design and implementation phases. An additional requirement is that a system of this type cannot be developed through a linear process, but arises from an evolutionary one. A key consideration is that evolution requires some stability point, to allow the convergence and the growth of the system. In our case the stability points are: – The knowledge model at the specification level; – A two level architecture (a simulator implementing the knowledge model and a level of added functions to exploit the model).

5 INTEGRATION AT SPECIFICATION LEVEL INTEGRATION AT SPECIFICATION LEVEL The specification document includes two main contents. The first content describes the intended users and the general scenarios of use. This part sets the general framework of the system, defining the scope of the possible application. It is of great relevance a clear identification of the goals because it affects the types of knowledge we need and the characteristics of the overall system. E.g., in our system there is a requirement to support multiple levels of modeling accuracy for the seismic vulnerability evaluation, according to multiple cost levels for the associated data survey. The second part of the specification (the core part) is not a list of functions or use cases but a model, defining the knowledge modules, the flow of information between them and the associated constraints.

Software based knowledge integration for seismic risk management

1027

Figure 1. A fragment of the knowledge model. Fig. 1 shows a fragment of the knowledge model. Rectangles represent the following computational models: 1 A set of vulnerability models; 2 A set of damage models; 3 A model computing the damage, given the vulnerability and a seismic input; 4 A procedure for the conversion to a uniform damage scale. The grey circle represents a persistent data structure. In the example it is a vulnerability/damage data set. White circles represent flows of data. From left to right in the figure: seismic input with site effects, vulnerability and damage. The modeling language is an interpreted Petri net, composed of activities, resources and relations between them. A computational module is an activity; a data module is a resource; activities may have input and output relations with resources and may exchange messages; an activity may have an associated annotation defining constraints. The model is used to interact with the experts, identify the modules to be integrated and link them to other modules. The model is also used to discover problems (e.g. the need of a new module to generate a common scale of the damage score coming from a number of vulnerability/damage models). The model is also the place where to add and integrate new fragments of knowledge as far as the system evolves. 6 INTEGRATION AT DESIGN AND IMPLEMENTATION LEVEL The integration issue is managed at design and implementation level through the following main technical choices: – A two-layer architecture. – The implementation of the person/machine interface in a GIS environment.

Ework and ebusiness in architecture, engineering and construction

1028

Figure 2. System architecture. The system architecture implements the well-known approach of the separation between the model and the functions exploiting the model (see the Model View Controller pattern or the Jackson System Design approach). The architecture (Fig. 2) is based on two layers: – A simulator – A layer of functions (the tools layer) to exploit the simulation capabilities according to specific goals and contexts. During the evolution steps of the system, the simulator is the more stable part implementing the knowledge model. The tools may be added or modified on top of the simulator, exploiting the simulation capabilities for specialized purposes. The evolution at tools levels may be managed with minor modifications at simulator level. The simulator implements the knowledge model through a relational database (the alphanumeric data modules), a set of GIS layers (the geo-referenced data layers) and a set of procedural modules (the models). The combination rules are encoded procedurally. The simulator in composed by three groups of interlinked sets of modules modelling the seismic hazard, the vulnerability and damage and the loss estimation. The tools layer includes the person/machine interface and a number of specialized tools. The person/machine interface is based on a GIS environment. Through the interface, the user can define a seismic source on a map of a region, propagate the effects and see the results on a coloured map at regional scale. Then the user can focus on an urban nucleus, apply the local soil effects, choose a set of survey data for the assessment of the vulnerability of buildings, choose a suitable model, compute a damage map and visualize a map of losses. The basic capability of the person/machine interface is to allow a step-by-step simulation, choosing among alternative models (with the associated constraints). An additional capability is the execution of a step-by-step simulation in the “recording mode”. The scenarios simulation may include steps of both the simulation scales

Software based knowledge integration for seismic risk management

1029

(regional level and urban nucleus). At each simulation scale, it is possible to use all the implemented functions, such as hazard, damage and losses. The sequence of steps may be stored, classified and re-executed later. The recorded scenarios can be used for nonspecialist final users (e.g. for civil protection preparedness). Finally, the “tools” level may be extended adding new applications that exploit the simulation capabilities. The current implementation makes available a tool for emergency preparedness support and another one for planning and loss reduction support. The hardware/software platform is the following: – Personal computer with a Windows operating system; – Microsoft Access Data Base Management System; – Mapinfo Geographical Information System.

7 CONCLUSIONS The tool is the evolution of a number of projects funded by E.U. and Italian National Research Bodies: – CNR (Italian National Research Council)—Progetto Finalizzato Edilizia, “Expert systems and mobile laboratory for seismic risk assessment of buildings” (Cadei 1992); – TOSQA—Earthquake Protection for Historic Town Centers (EV5V-CT93-0305) (TOSQA Report 1 and 2, 1996); – SCENARIO: Time dependent seismic hazard estimate based on multi-parameter geophysical observatory system (PL931989) (Salvaneschi 1996 and SCENARIO 1998); – SEISMOCARE (ENV4-CT97-0588) (Anagnostopoulos 1998 and SEISMOCARE 2001). The tool, during the evolution steps, has been used for seismic risk assessment in a number of situations. Among them: the urban nucleus of the Alfama district in Lisbon, the area of “Quartieri spagnoli” in Naples, the region and the city of Chania, a Greek city on the island of Crete and the town of Genova, Department of Quindío, Colombia. REFERENCES Anagnostopoulos S.A., Bonacina G., Gavarini C., Nisticò N., Providakis C., Salvaneschi P., Sotiropoulos D., Woo G., 1998. Computer aided Reduction of Seismic Risk with Application to existing Cities, Town planning and Construction (SEISMOCARE) SISM-98 Seismic Impact on Structures and Monuments, Cambridge, UK. Cadei, M., Panzeri, P., Peano, A., Salvaneschi, R., 1992. A mobile laboratory with an expert system for seismic assessment of buildings. Proc. of the Tenth World Conference on Earthquake Engineering, A.A.Balkema, Rotterdam, 6311–6316. Salvaneschi R., Mucciarelli M., Spinelli A., Console R., Valensise G., Stavrakakis G.N., 1996. Time Dependent Hazard Estimate based on a Multi-parameter Geophysical Observatory System XXV General Assembly of the European Seismological Commission (ESC), Reykjavik. SCENARIO Final report, 1998. Environment project PL931989, Time dependent seismic hazard estimate based on multi-parameter geophysical observatory system (SCENARIO).

Ework and ebusiness in architecture, engineering and construction

1030

SEISMOCARE Final report, 2001. Environment project EV5V-CT97-0588, Computer aided Reduction of Seismic Risk with Application to existing Cities, Town planning and Construction (SEISMOCARE). TOSQA Report 1, 1996. Environment project EV5V-CT93-0305, Eartquake Protection for Historic Town Centres (TOSQA), Task 2: Case studies. Task Report: Survey Data Analysis and Comparative Assessment. TOSQA Report 2, 1996. Environment project EV5V-CT93-0305, Earthquake Protection for Historic Town Centres (TOSQA), Task 5: Develop Vulnerability Methods and propose Strategies for Retrofitting. Task Report: Adapt Vulnerability Methods examined by IGOR to incorporate Retrofit.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) ©2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Real-time earthquake prediction algorithms S.Radeva University of Architecture, Civil Engineering and Geodesy, Sofla, Bulgaria R.J.Scherer Dresden University of Technology, Germany, EU D.Radev University of Rousse, Rousse, Bulgaria ABSTRACT: The paper is devoted on the problem of real-time earthquake prediction. Different kinds of stages of earthquake prediction are observed, and for each of this stages are discussed implementation of existing algorithms M8 and MSc for intermediate-term middle-range prediction. An approach for real-time prognoses, based on classification algorithm of strong motion waves with neural network and fuzzy logic models is suggesting. As input information for the neural network are given the parameters of recorded part of accelerogram, principle axis transform and spectral characteristics of the wave. With the help of stochastic long-range dependence time series analyses is determined the beginning of destructive phase of strong motion acceleration. Developed seismic waves classification gives possibility to determine the method for real time prognoses. For different king of classified waves we suggest different kind prognoses models. The prognoses are realized with the help of neural network, build on the principle of vector quantization.

1 INTRODUCTION A very promising method in earthquake engineering for protection of height—risk and very important structures against destructive influence of seismic waves is anti-seismic structural control. One of the critical problems there is the problem of forecasting in realtime of the behavior of seismic waves. Prognoses for further development of the waves can be made from recorded in real-time data for certain part of destructive seismic waves registrated in three directions. These prognoses are based on general, tectonic, seismic and site parameters. During these prognoses is supposed that waves can be classified as destructive or non-destructive and can be taken decision for switching on the devices for structural control. For making prognoses it is necessary to develop different kind of models. Modeling gives possibility to study the behavior of seismic waves and relationships between their parameters during their spread in soil layers, where for each point the parameters of her displacement are presented with three components in three directions of the orthogonal

Ework and ebusiness in architecture, engineering and construction

1032

axes. For practical purposes of possible records for displacements, velocities and accelerations as time history, most often accelerograms are used, which are characterized with certain duration, frequency and peak ground acceleration. They are involved in models and systems for estimation of elasticity response spectrum. The most practical usage in structural engineering and design has their peak values, independently of their sign and direction. That’s why the modeling of the behavior of seismic waves is used as input information in the process of calculation of the structural response spectrum. The prognoses of earthquake occurrence can be classified according to the prognoses time duration. The most popular is their dividing into long-term (for next ten years), intermediate-term (for next few years), short-term (for next months-weeks) and real-time. Other kind of prognoses is prognoses of the area of occurrence of earthquake excitation of certain magnitude. Both approaches for prognoses are connected with difficult problems, when are applied the traditional stochastic time series analyses instead of applying methods for crash prognoses, where is dealing with reaching of certain critical threshold, (Kossobokov et al, 2000). Concerning the gap stretch of expected earthquake GLe it is necessary to take the space localization in more wide diapasons. The classification of kind of earthquake prognoses is presented on Table 1.

Table 1. Classification of earthquake prognoses according to time and place determination. Temporal in years

Spatial in sources zone GLe

Long-term

10

Long duration up to

100

Intermediate-term

1

Middle duration

5–10

Short-term

0.01–0.1

Short duration

2–3

Real-time

0.0001

Exact

1

In this paper we fix our attention on real-time prognoses of earthquake excitation, which is very important, because we have to receive very precise estimation of the development of the process. The method for classification is developed for fast estimation of strong motion seismic waves on the base of their main characteristics. The fast estimation of seismic waves is implementing for real-time prognoses, which is based on belonging of prognoses waves to certain class and subclass. 2 INTERMEDIATE-TERM MIDDLE-RANGE PREDICTION An earthquake prediction must specify the expected magnitude range, the geographical area within which it will occur, and the time interval within which it will happen with sufficient precision so that the ultimate success or failure of the prediction can readily be judged. The two basic intermediate-term algorithms M8 and MSc are comparing in this section.

Real-time earthquake prediction algorithms Real-time earthquake prediction algorithms

1033

2.1 Algorithm M8 This prediction method was designed by retroactive analysis of dynamics of seismic activity preceding the greatest, magnitude 8.0 or more earthquakes. Its original version (Keilis-Borok & Kosobokov, 1990) were tested retroactively at 143 points, of which 132 are recorded epicenters of earthquakes of magnitude 8.0 or greater from 1857–1983. The catalog of main shocks canbe described by {ti, mi, hi, bi(e)}, i=1, 2,…, where ti is the origin time, hi is the focal depth, mi is the magnitude and bi(e) is the number of aftershocks with magnitude Maft or more during the first e days. On Figure 1 are shown dependences between two main approaches for earthquake prediction with M8 provided by Keilis-Borok (1) and Gardner-Knopoff (2). According to M8, the prediction is aimed at earthquake of magnitude M0 and larger from the range M0+= [M0, M0+DM], where DM<1. The magnitude scale should reflect the size of earthquake sources. The algorithm is realizing via calculating overlapping circles, with diameter D(M0)=(exp(M0–5.6)+1)° in degrees of the Earth meridian, scanned seismic region under study. The received sequence of overlapping circles is normalized being the standard value of the by the lower magnitude cutoff average annual number of earthquakes in the sequence. Several running averages are computed for this sequence in the trailing time window (t−s, t) and magnitude range . They depict different measures of intensity in earthquake flow, its deviation from the long-term trend and clustering the earthquake. The averages determine range and acceleration of activity.

Ework and ebusiness in architecture, engineering and construction

1034

Figure 1. Dependences between magnitude and distance from epicenter (up), and magnitude and time in days (down). Let the rate of activity (number of events of certain size per unit time) is given by the number of earthquakes N(t1/2m, s) with magnitude M≥m in time interval from (t−s) to t. The differential of the rate of activity is denoted by L(t|m, s, t0), which is deviation of activity from a longer-term trend over the period from (t−s) to t. this deviation is calculating according to (1).

Real-time earthquake prediction algorithms Real-time earthquake prediction algorithms

1035

(1)

After determining the rate and acceleration of activity is determining linear concentration of main shocks {i}–Z(t) according to (2), (2) where magnitude range is m≤Mi<M′ and the interval t−s≤ti
of

functions

N,

L,

Z

is

calculated

twice

for

m,

where

. As a result, the earthquake sequence is given a robust averaged description by seven functions: N, L, Z (twice each) and B−N1, N2, L1, L2, Z1, Z2, B. The algorithm M8 uses traditional description of a dynamic system adding to a common phase space of rate Z and rate differential L, dimensionless concentration Z and a characteristic measure of clustering B. The algorithm recognizes criteria, defined by extreme values of the phase space coordinates, as a vicinity of the system singularity. When a trajectory enters the criteria, probability of extreme event increases to the level sufficient for its effective provision, as shown on Figure 2. Effective prediction with M8 is reached in 16% of predictions. Modified version for lower seismic activities prediction has reached 42% of predictions. 2.2 Algorithm MSc This algorithm for reducing area of alarm was designed by retroactive analysis of the Eureka earthquake (1980, M=7.2) near Cape Mendocino in California, that’s why its name abbreviated to MSc. The algorithm outlines such an area of the territory of alarm where the activity, from the beginning of seismic inverse cascade recognized by the first approximation prediction algorithm is continuously high and infrequently drops for a short time. The phenomenon, which is used in MSc might reflect on second stage (possibly shorter term, narrow range). In this second stage seismic activity may rise near the incipient source of main shock. Let given a TIP diagnoses for a certain territory U at the moment T, the algorithm attempt to find within U a smaller area V, where the predicted earthquake can be expected. The algorithm requires a reasonably complete catalog of earthquakes with magnitudes M=3(4), which is lower than the minimal threshold used by M8.

Ework and ebusiness in architecture, engineering and construction

1036

The territory U is coarse-grained into small squares (s×s) and determines the centers of the squares (i, j). Within each square the number of earthquakes and aftershocks is calculated for consecutive, short time windows and k is the sequence number of a trailing time window. Finally, the time-space considered is divided into small boxes (i, j, k) of the size

Figure 2. Algorithm M8 criteria in the phase space. (s′, s′, u). “Quiet” boxes are singled out of each small square with coordinates of it centre (i, j) and clusters of q or more quiet boxes connected in space or in time are identified. Area V territorial projection of these clusters. The prediction is localized to a spatial projection of all recent “sufficiently large” clusters of squares being in state of “anomalous quiescence”. The standard values of

Real-time earthquake prediction algorithms Real-time earthquake prediction algorithms

1037

parameters are u=2 months, q=4 and s=3D/16, where D is diameter of the circle used in algorithm A8. The algorithm MSc outscores simple alternatives of narrowing down the area of first approximation alarm, in which are included “nonempty cells” and “most active cells” that contain a part of recent seismic activity. At second approximation is improving accuracy by more detailed determination of the “weight centers” of the squares. Effective prediction with MSc is reached in 18% of predictions. 3 REAL-TIME PROGNOSES WITH VECTOR QUANTIZATION The suggested method for real-time prognoses is developed for fast estimation of strong motion seismic waves on the base of their main characteristics. The fast estimation of seismic waves is based on belonging of prognoses waves to certain class and subclass. The proposed real-time classification and prognoses are realized with neuro model, which is based on Learning Vector Quantization (LVQ). The classification helps to select proper prognoses stochastic model for each of selected classes or subclasses. The principle of it functionality is presented on Figure 3, where is shown an example for prognoses model for destructive S-phase of class1—classic. On the base of the registrated input part of time series {xk,p−n,…, xkp} are made prognoses of the next values {xk,p+1,…, xk} of time series {xk}. The neural network has two layers: a first competitive and a second linear. The competitive layer learns to classify the input vector. It learns all subclasses that belongs to the linear target layer SM=SM1, SM2,…, SMM. The module of vector quantization (VQ) gives density distribution between classes in such a manner that in each class we have the same number of target values. The linear layer transforms the competitive layer’s classes into target classifications defined by the user. The competitive neurons of the vector i will have weights of 1 to one neuron in the linear layer, and weights of 0 to all other linear neurons.

Ework and ebusiness in architecture, engineering and construction

Figure 3. Real-time neuro modelling of destructive phase of strong-motion seismic waves.

1038

Real-time earthquake prediction algorithms Real-time earthquake prediction algorithms

1039

LVQ learning in the competitive layer is based on a set of input/target pairs. Each target vector has a single 1 and the rest of its elements are 0. The 1 tells the proper classification of the associated input. With LVQ we determine the fimction of density distribution with amplitudes, received from the real accelerograms. The vector quantization gives density distribution for each class and redistributes the target values in such a manner to have the same number of target values in each class (Radeva et al, 2004). The density distribution of the values of time series was received via approximation of the linear target layer SM of the vector quantization. For the proper determining of the function of density distribution is necessary to optimize the approximation of the target layer. The network was trained to classify the input space according to parameters of scene-oriented model. It is a modification of simple Markov chain model, where the time series {xt} was transformed into discrete states {yt}, where the number of states Ì, is the same as the number of target classes, and the size of the model yi for each state is determined. With the help of LVQ is determining the optimal number of target classes and prognoses is realizing with this number. 4 CONCLUSIONS Real-time and intermediate-time earthquake prognoses are discussed. The two basic algorithms for prognoses of intermediate-term and short-term prognoses are discussed. Real-time prognoses algorithm for prognoses of destructive phase of strong motion seismic waves is suggested the algorithm is realized with the help of stochastic models and neural network, build on the principle of learning vector quantization. In real time are generating the statistical function of density distribution of recorded data from accelerogram. The received prognoses values are comparing with real ones for continuous updating of the model. Received results can be used in system for structural control and in process and product modelling This work is a part of the International NATO research project No: PST.CLG.979333. REFERENCES Keilis-Borok, V.I. & Kossobokov, V.G.1990. Premonitory activation of earthquake flow: algorithm M8. Phys. Earth Planet. International 61: pp. 73–83. Kossobokov, V., Keilis-Borok, V., Turcotte, D. & Malamud, B. 2000. Implications of a statistical physics approach for earthquake hazard assessment and forecasting. Pure Applied Geophysics 157: pp 2323–2349 Radeva, s., schere, R., Radev D. & Yakov, V. Real-time estimation of strong motion seismic waves, Acta Geodaetica et Geophysica Hungarica, Vol. 39 (2–3), 2004, pp. 297–308.

IT supported architectural design

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) ©2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Hybrid approach to solve space planning problems in building services G.Bi & B.Medjdoub School of the Built Environment, University of Nottingham, Nottingham, UK ABSTRACT: In this paper an object-based CAD programming is used to take advantage of standardization to handle the schematic design, sizing, layout for services in a building ceiling void. From the specification of the building 3D model, our software proceeds through different steps; from the determination of the standard number and size of the fan coils to the generation of 3D solutions. In order to deal with more complex geometry and larger problems, we have used a hybrid approach: Case Based Reasoning (CBR) within Constraint Satisfaction Problem (CSP) approaches. In practice, engineers in building services use previous solutions and adapt them to new problems. CBR mirrors this practical approach and does help us to deal with increasingly complex geometry effectively, and meanwhile CSP has been used for layout adaptation.

1 INTRODUCTION Standardization is widely recognized as a key element in reducing design time, cutting construction costs and ensuring efficient design solutions. The previous project “Building Services Standard Solutions implemented in CAD” (Medjdoub et al. 2003) has shown that it is possible to define and implement standard solutions to produce designs comparable with the practice. The previous project dealt with middle size problems within simple geometry using constraint-programming technique to implement the design rules and the solution generation algorithms. In this project, our approach uses standard solutions in conjunction with IT and extends the work of the previous one for fan coils to make the solutions useable for more complex geometry. This will bring the benefits in terms of increasing the range of applications for which the solutions can be used (with consequent reductions in design time etc.) and to improve its usability. The extension to deal with more complex geometry will be based on Case Based Reasoning (CBR) (Dave et al. 1994) (Sqalli et al. 1999) (Aamodt & Plaza 2000) as well as Constraint Satisfaction Problem (CSP) approach. Very often, design engineers retrieve similar solutions from the case based and adapt them to new problems. CBR mirrors this practical approach and will help us to deal with increasingly complex geometry effectively. In this paper we do not deal with pipe routing. The objectives of the project are:

Hybrid approach to solve space planning problems in building services

1043

– Implement the standard solutions in an industry standard CAD system using advanced techniques in Artificial Intelligence combining CBR with CSP. – Develop an interactive and friendly user interface, simply to use with a high-level modification of the 2D and 3D solutions. – Test and evaluate the standard solutions against conventional ones in a benchmarking exercise with our industrial partners.

2 FAN COIL STANDARD SOLUTIONS The standard solutions were developed in consultation with practicing engineers. They are essentially a collection of rules that address the selection, sizing and the location of services equipment in the ceiling void. The rules are in a number of different forms including: – Schematics – Written rules – Geometric layouts The ceiling void solution is based on a four-pipe-fan-coil system. Fresh air is provided by a central air-handling unit. Air supply to the space is via slot diffusers in the perimeter zones and the square diffusers internally. Whereas with plant rooms, the main integration issues are between different services elements, for ceiling voids the emphasis is more on integration with non-services elements including beams, ceiling tiles and core areas. It is firstly necessary to define these before the suited services solution can be generated. In practice, once the non-services elements have been defined, the services are located approximately in order from the most to least geometrically constrained. For the structural solution illustrated in Figure 1, the distribution runs are located next as these are constrained to pass through the beam holes. These are then followed in sequence by; diffusers selected to provide the required air flow and located to integrate with the lighting; fan coils selected to meet the zone load requirements and located to ensure maintenance access from below; ductwork from fan coils to diffusers; distribution ductwork (for air flow) and pipe work (for cooling water) to the fan coil units (where not routed through beams and columns); condensate runs from the fan coils to column droppers.

Ework and ebusiness in architecture, engineering and construction

1044

Table 1. Four-pipe ceiling mounted fan coil system as the HVCA standard. Ceiling voids

Type

General

Locations The equipment location sequence is generally as follows: —Luminaries —Diffusers —Fan coil units —Pipework —Ductwork Equipment (i.e. diffusers and lights) should not be located in adjacent tiles unless there is a reasonable margin around equipment.

Fan coil units

Selection Units selected from manufacturer standard range using chilled water for cooling and LPHW for heating as required.

Diffusers

Rules

Sizing

Following variables defined for selecting size of fan coil units: —Total air volume —Fresh air volume —Cooling required —Heating required —External pressure drop —Noise level If largest unit not big enough to serve zone, then treat with 2 of the same type, then 3 of the same type, and so on.

Location

Heating and cooling pipe work connections staggered to assist coordination. Locate fan coils on riser side of zone to minimize condensate and other pipe work runs and air flow direction changes from the risers through unit to the diffusers (see Figure 2). Locate 50–100 mm below slab to allow for slab inconsistencies and slope towards drain exit. Limit distance to diffusers to keep pressure drop down.

Selection Perimeter zones—slot diffusers selected from manufacture standard range. Internal zones—square diffusers selected from manufacture standard range. Sizing

Use manufacturers sizing algorithms to meet throw, pressure drop and noise requirements.

Location

Located square diffusers to nearest possible location to suit lighting layout. Locate slot diffusers along perimeter.

Ductwork Selection Local ductwork from fan coils to diffusers circular. Distribution ductwork circular up to 200 mm, flat oval above to limit depth requirement. Use standard ISO/DW144 ranges (DW144 1998). Use fittings as defined by BSRIA (1995) Standard Details project. Sizing

Use CIBSE Guide (2001). Local ductwork from fan coils to diffusers sized as plenum spigot connection subject to a maximum velocity of 3 m/s. 5 m/s maximum velocity limit for ductwork distribution to fan coils.

Hybrid approach to solve space planning problems in building services

Location

1045

Run duct and pipe work headers out from riser and tap off to fan coil units. Route ductwork through cellular beams if possible, otherwise run below beams. Route ductwork down centre of area to be served. Branch supply ductwork local to risers to facilitate crossovers.

Pipe work Selection Use fittings as defined by BSRIA Standard Details project. Sizing

For LPHW and CHW pipe work use CIBSE Guide C “steel pipe” bigger and higher k factors). Base sizing on 200Pa/m and never exceed 250 Pa/m.Size condensate at 20mm from units, 40 mm for 2 or more units, and 50 mm in risers.

Location

Try to run in pairs (side by side) for F & R but not essential. Reverse return arrangements preferred where possible. Share commissioning sets if adjacent units similar (cost and commissioning benefits) running pipe work with a self-balancing “T”. Route through cellular beams if possible, otherwise run below beams.

The rules and solutions documented in the table (Table 1) are for a four pipe ceiling mounted fan coil system as the HVCA (DW144 1998) standard solution.

Figure 1. 2D ceiling voids layouts.

Ework and ebusiness in architecture, engineering and construction

1046

Figure 2. Ceiling void layouts—fan coils. 3 OBJECT MODELS OF CEILING VOIDS SOLUTION The object model holds three main classes of objects representing the ceiling voids space geometry, equipment and pipe work. Each class is characterized by attributes and constraints. 3.1 Space The space class contains two sub-classes: the zone class and the structural element class (e.g. column and beam). The zone geometry can vary from a simple rectangle to an ellipse or a curved shape with known obstructions, doors and external walls. The attributes of a zone depends on its shape, if the zone is a polygon it will be defined by a set of points (X[n], Y[n], Z[n]) which represent the polygon vertexes, where n equals to the number of all vertexes. The internal structure is characterized by a reference point, its length and its width. 3.2 Equipment The equipment class includes the fan coil and the diffuser classes. These classes are characterized by a reference point (X, Y, Z), a length, a width, a height and an orientation attribute defined as a constraint discrete variable defined over the domain {0°, 90°} (see Figure 3, Top-Left).

Hybrid approach to solve space planning problems in building services

1047

Figure 3. (Top-Left) the size and distance attributes of fan coils and diffusers. (Bottom-Right) geometrical representation of pipe with set of 4 points (P1–P4) corresponding to 3 segments, 2 bends.

3.3 Pipe The pipe class is defined by a set of points (X[n], Y[n], Z[n]) and a radius R. Each pair of successive points defines a segment of the pipe, each segment has an orientation variable defined over the domain {0°, 90°, 180°, 270°}. A class constraint is defined to ensure that two successive segments have different orientations. We consider the number of bends equal to the number of pipe segments minus one (see Figure 3, Bottom-Right). 4 CEILING VOID SPACE ALLOCATION PROCESS The generation of a solution will follow four main steps: 1. Definition of the fan coil number and type 2. Floorzoning

Ework and ebusiness in architecture, engineering and construction

1048

3. Case retrieving 4. Constraint-based case adaptation 4.1 Definition of the fan coil number and type Buildings have different functions like offices, shopping malls, hospitals, restaurants etc, and each one need a particular cooling and heating loads to serve the indoor environments. So only after defining the floor ftmction, we could deduce the fan coil number and

Figure 4. The floor is divided into 4 zones, which includes triangle, rectangle and elliptic zones. type. For example, if the floor is for an office use, the perimeter (window side) cooling load is 100 w/m2, and the setting is 6×4.5 m2 per fan coil. For the internal area (area far from the perimeter), the cooling load is 50 w/m2, and the setting is 50 m2 per fan coil1. To find out the appropriate fan coil type, we also need the necessary environment data like air density, specify heat capacity, cool temperature difference etc. All these data are saved in the application database, thus through the user interface the engineers have just to choose the floor function to generate automatically the appropriate fan coil type and the number. 4.2 Floor zoning In the case of a building within a complex shape, the user will through the user interface divide the building floors in zones. As indicated in Figure 4 the zones are simple geometric primitives (e.g. circle, rectangle, triangle, trapezoid and ellipse). We use the floor zoning in the case of complex building shape which will be divided in simple geometrical primitives. These zones are linked together with the joint sides, and

Hybrid approach to solve space planning problems in building services

1049

the unlinked sides are perimeter sides. The fan coils and the diffusers can be set within the perimeter (window) sides and the internal areas of different zones; finally the pipes will pass through the joint sides to connect them. Meanwhile, engineers are required to define the locations of columns, beams and internal structures (i.e. store rooms, lifts, stair rooms etc) where the pipes and the fan coils should not overlap (non-overlapping layout). For the locations of columns and beams definition, engineers are required to select all reference lines (the row and column base lines) which cross the columns. 4.3 Case retrieving After having defined the zones and their attributes, the next step consists on retrieving the most similar

Table 2. Key information to retrieve the case. Key information

Explanation

Shape type

Rectangle, trapezoid, triangle, ellipse, circle, arc or bspline curve.

Side number

In the case of a polygon

Horizontal side number

In the case of a polygon

Vertical side number

In the case of a polygon

Top vertex number

How many top vertexes with same Y value the shape has if it is a polygon.

Bottom vertex number

Vertexes with the same Y value, in the case of a polygon

Primary & second Radius Check whether the primary radius equal to the second radius when the shape is an elliptical curve. Joint side number & position

In the case of an elliptical arc, the joint side should be at the line perimeter.

Window side number & position

In the case of an elliptical curve, the window positions should be on the curve.

Fan coil arrangement

Type of the arrangement (i.e. horizontal or vertical).

Ework and ebusiness in architecture, engineering and construction

1050

Figure 5. (a) Incomplete solution generated by the case retrieving, one fan coil overlap with a column, (b) solution after local adaptation within the use of a non-overlapping constraint between the fan coil and the column. case from the case library. The solutions of fan coil systems for the basic geometrical floor shapes (rectangle, triangle, trapezoid, circle and ellipse etc) are stored in the case library, where the match between the floor zones and the retrieved similar cases is based on a descriptive index of the shape, which approach is called Case Based Reasoning (CBR). The matching information we need to know includes the zone shape (i.e. rectangle, triangle, ellipse etc), the side number of polygon, the position of joint and the window side etc. The table (Table 2) has listed the key information to retrieve the case. Then, from the case retrieving a first incomplete solution (see Figure 5a) is generated and will need further adaptation to make it usable. 1

Data provided by Faber and Maunsell.

4.4 Constraint-based case adaptation The adaptation process is based on the constraint programming techniques. The method used is by substitution, where we replace some parts of the old solution that do not fit the current situation requirements. Thus from the incomplete solution from the case retrieving step, the system will identify the incoherent parts of the solution, as indicated in Figure 5a, where one fan coil overlap with a column. Next this incoherency is solved using simple constraints (e.g. inclusion constraint, non-overlapping constraint, dimension constraint) to make it coherent. The advantage of this approach is that each incoherency is solved separately, which decrease drastically the complexity of the problem. To generate the new position of the fan coil (see Figure 5b) we use an heuristic based on a orthogonal grid which will help the enumeration process to instantiate the new coordinates (x, y, z) of the fan coil to be on this grid. 4.4.1 Dimension constraints Dimension constraints assign a minimal or a maximal value to the object constrained variables. This constraint is expressed by equality or inequality. 4.4.2 Inclusion constraints Inclusion constraints represent the object must be within the space. These types of constraints are especially important for finding the locations of fan coils and diffusers, where they must be located within their local grid areas.

Hybrid approach to solve space planning problems in building services

1051

4.4.3 Non-overlapping constraints Non-overlapping constraints represent the fact that two objects cannot overlap each other; it is automatically applied to all pairs of objects in our application (i.e. fan coil to structures, fan coil to fan coil etc). For objects with regular and irregular shapes, there are different non-overlapping solutions. For rectangular shapes (i.e. it could be applied for a L-shape or T-shape), nonoverlapping constraints introduce a new non-overlapping variable with 4 elements {North, East, South, & West}. These orientation variables are represented in order to avoid making two objects overlapped. 5 IMPLEMENTATION & BENCHMARKING This application is developed in JMDL (Java Modelling Language) as embedded in Microstation/J and JSolver the constraint programming system. Microsoft Access, the relational database application is used for the case library. Finally we use Microstation/J to layout the object model and the 3D rendering.

Ework and ebusiness in architecture, engineering and construction

1052

Figure 6. User interface panels to fan coil layout. The implementation includes the user interface, the CBR library as well as the constraint library within the algorithms for the case adaptation and the solution enumeration. The user interface is composed of several panels (see Figure 6), which include the data input, the zoning process and the equipments (fan coils and diffusers) generation. The main information that the user need to input are: – The floor information which includes floor drawing unit (i.e. millimeter or meter); floor type (i.e. office, shop, hospital etc); floor noise requirement NR; floor height, ceiling voids height. The system will then generate automatically the type of fan coils based on the rules of thumb. – The diffuser information which includes the diffuser size, the interval sizes of diffusers, the minimum distance from the diffuser to wall and to window. The user can modify

Hybrid approach to solve space planning problems in building services

1053

these parameters (i.e. perimeter and internal area sizes, area load rate, air density, etc.), which are already saved in the database. – The building structure grid (i.e. indicating the location and the size of columns and beams). – The zone, by selecting the shape and the system will automatically generate the zone information (i.e. zone area and zone position). The user needs to define the window and joint sides of the zone by selecting the appropriate sides. – The internal structure and the riser, lifts, stair cases, and function rooms. The location of the riser which gives the starting position of the pipe routing. The results have shown that it is possible to define and implement standard solutions to produce designs comparable with current practice. This benchmarking exercise has underlined many advantages and made some suggestions for further development. The main advantages are: 1. The system deals with complex floor shapes. 2. The retrieving of the similar case is done in reasonable time. 3. The constraint-based adaptation approach is done sequentially which decrease the complexity of the problem. 4. The output from the solutions such as the 3D data model is beneficial to other parties in the supply chain. The main improvements needed: 1. To deal with curved shapes. 2. To enrich the case library. 3. To develop a retain solution mechanism. 4. To develop further more the interactivity of the system.

6 CONCLUSION This approach has shown the potential to significantly reduce design costs by reducing design time, improve the quality of the solution and produce additional benefits elsewhere in the supply chain. On the computational part, the integration of CBR and CSP approaches did achieve a synergy, which produces the results that could not be obtained if each mode were operating individually. Further developments are being done and concern mainly the case library enrichment and the complex problem of pipe routing. The idea to have a compromise between full automation and interactivity gives to the designer full control of the design while assisting him to solve complex problems automatically. This compromise is the main difference with the a forementioned approaches in facilities layout and pipe routing. In our application, several aspects were discussed which include case based reasoning approach, constraint satisfaction approach, algorithm and rules of layout solution enumeration.

Ework and ebusiness in architecture, engineering and construction

1054

ACKNOWLEDGEMENTS This project is funded by the EPSRC2 in the UK. There are three industrial partners including Faber and Maunsell, Bentley Systems and Biddle Air Systems. The authors would like to thank Mr Nick Barnard from Faber and Maunsell and Mr Mike Price from Biddle Air Systems for their valuable help and comments about various aspects of this research project. REFERENCES Aamodt, A. & Plaza, E. 1999. Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches, AI Com—Artiflcial Intelligence Communications, Vol. 7, No. 1. BSRIA report 2001. Rules of thumb, Technical Note TN15/01, BSRIA. CIBSE Guide C, Reference Data. 2001. Section C4 Flow of Fluids in Pipes and Ducts. Dave, B. Schmitt, G. Faltings, B. & Smith, I. 1994. Case based design in architecture, Artificial Intelligence in Design -AID’94, Kluwer Academic, p. 145–162. DW 144. 1998. Specification for sheet metal duct work-Low, medium and high pressure/velocity air systems, HVCA. Medjdoub, B. & Yannou, B. 2000. Separating topology and geometry in space planning, Computer Aided Design, 32(1), p. 39–61. Medjdoub, B. & Yannou, B. 2001, Dynamic space ordering at a topological level in space planning, Artificial Intelligence in Engineering, 15(2001), Elsevier Science Ltd, p. 47–60. Medjdoub, B. Richens, P. & Barnard, N. 2003. Generation of Variational Standard Plant Room Solutions, Automation in Construction, 12(2), Elsevier Science Ltd, p. 155–166. Sqalli, M.H. Purvis, L. & Freuder, E.C. 1999. Survey of Applications Integrating Constraint Satisfaction and Case-Based Reasoning, PACLP99: International Conference and Exhibition on the Practical Application of Constraint Technologies and Logical Programming. 2

The Engineering and Physical Sciences Research Council.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

A computational architectural design approach based on fractals at early design phases Özgür & Gülen Çağdaş Istanbul Technical University Faculty of Architecture, Istanbul, Turkey ABSTRACT: In this paper, a three-dimensional form generator based on fractal dimension will be presented. Fractal dimension is used as a means of capturing the pattern appropriate at the compositional configuration of a historical architectural language and generating new forms which will ensure the continuity of this language. The formal compositions are represented by generative algorithms in this approach. The generative algorithms are coded in the C++ computer programming language. An animation algorithm is also developed by using ‘DirectX’ software. The generation process describes how to derive a compositional configuration from other forms with different dimensions which can be generated by changing fractal dimensions.

1 INTRODUCTION Digital design technologies have an important role in supporting the designer at the conceptual architectural design phase. Computer supported design systems can generate different images during the early design process and can provide useful inputs when searching for alternative forms of architectural design products. In the literature, there are different computational architectural design approaches. Some researchers consider the design problem as a problem-solving process based on the information-processing theory of Newel and Simon. HeGel-II (Akin and Sen, 1994), SEED (Flemming, Aygen, Coyne and Snyder, 1997), WRIGHT (Baykan and Fox, 1997) APSIS (Kisacikoğlu and Çağdaş, 2004) models are the examples that support the early design phases by generating the alternative layouts. Another computational design approach is the shape grammar formalism stated by Stiny (1980). Queen Anne Houses (Flemming, 1987), Bungalows of Buffalo (Downing and Flemming, 1981), the Prairie Houses of F.L.Wright (Koning and Eizenberg, 1981), Row Houses ( Çağdaş, 1996a), Traditional Turkish Houses (Çağdaş, 1996b), Gedit (Tapia, 1999), Coffee-maker (Agarval and Cagan, 1998), Alvaro Siza’s Houses (Duarte, 1998) are some of the examples of the shape grammars. Most of these works generate two-dimensional models of design products. In this paper, a three-dimensional form generator based on fractal dimension will be presented. Fractal geometry has begun to be used with the aim of supporting a new approach in generative architectural design. Images based on fractal geometry can be

Ework and ebusiness in architecture, engineering and construction

1056

generated by algorithms and are used in the formation of surfaces, structures and forms. Shape grammars are applications in which shapes are represented as design descriptions and transformed according to a rule-based formalism. Generation processes can be modeled on the transformations of shapes. A shape grammar contains a vocabulary, a set of shape rules and an initial shape. Form alternatives can be generated by applying the shape rules recursively to the initial shape. Fractals are a subset of shape grammars. In fractal approach, the number of rules are small, the number of recursions high and self similarity is guaranteed in comparing shape grammars (Schmitt and Chen, 1991). In this study, fractal dimension is used as a means of capturing the pattern appropriate at the compositional configuration of a historical architectural language and generating new forms which will ensure the continuity of this language. The aims of this study are: • To support the creativity of designers at the early design phases; • To generate and give a preliminary ranking to the form alternatives; • To explore the potential of digital design technologies in the computational architectural design process.

2 GENERATION OF FORM ALTERNATIVES The computer is a powerful medium that generates complex spatial compositions in the architectural design process. For producing designs, two major computer-based strategies are used. These approaches have been characterised by Coyne as generation and abduction (Coyne et al., 1990). The generative approach involves the use of knowledge in the form of grammar rules or generative algorithms, for producing designs conforming to an architectural language. In the abductive approach, use is made of knowledge to reason directly from design requirements (Yoon and Coyne, 1992). In other words, abductive reasoning is to consider knowledge that relates explicitly to the manipulation of design constraints. The starting point of the theory behind computing in architectural design is based on Aristotle’s concept of a generative system that can provide a variety of potential solutions to a problem (Mitchell, 1977). Systematic use of generative systems in architectural design was applied by Leonardo Da Vinci who generated central plan churches. Durand used this systematic approach for the generation of plans and elevations from different combinations of building elements. The computer application of this principle is the approach of shape grammar or design grammar. It is based on generation of shapes according to parametric shape rule schemata. Applications of shape grammars and other grammatical formalisms in architectural and engineering design have been growing steadily and impressively (Knight, 1998). After defining the grammar of an architectural language, a computer can be used to generate forms in the context of parametric and innovative architectural design. This approach also supports the creative architectural design process. Similar to this approach, forms based on fractal geometry can be generated at the early design phase.

A computational architectural design approach based on fractals

1057

In this study, a generative design approach supporting creativity in the production of new forms by using the fractal dimension of a certain architectural language is presented. In the development of this approach, the following stages have been carried out: • Using the Curdling Method, an algorithm has been developed which is formed from selected units and with the intention of forming different settlement patterns showing fractal features. • A generative algorithm has been developed which creates different forms by applying different fractal values to an initial shape. • With the aim of producing data for the application of the algorithms developed, an existing architectural pattern has been selected. By examining the Fethiye/Kayaköy settlement, chosen for its characteristic architectural pattern, its fractal dimensions have been calculated in its settlement, street and dwelling scales. In calculating the fractal values, the box-counting method of Bovill (Bovill, 1996) has been used. • By using the fractal value of the Kayaköy settlement and of a selected street pattern, alternative solutions have been produced which will ensure the continuity of the pattern in new design projects, by applying the typological and fractal dimension of the dwellings to the algorithms developed. In order to apply the suggested approach, the fractal values of first of all the settlement, then one of the streets of this settlement and finally the dwellings in this street possessing a different plan concept have been calculated. The values, obtained by means of the box counting method, have been interpreted on the settlement, street and dwelling levels. As a result of this evaluation, the existence of the continuity of the pattern has been investigated, and the relationship between dwelling and topography has been examined. The values obtained with the calculation of fractal value have been used as data for the new pattern to be created. The algorithm developed for generating forms presents different alternatives depending on different fractal dimensions. For this algorithm, alternative forms have been created which, by the application of fractal values belonging to the existing architectural pattern, will be able to reflect the continuity of the pattern in fractal concepts. The creation of algorithms aimed at generative architectural design was begun first of all with the collection of plans obtained in an architectural shape grammar library. The finding of separate typological features of each room in every dwelling and of the other units was assisted by the formation of the shape library. These libraries have been used as input in the algorithms developed for the formation of generative fractal settlements. With the aim of forming architectural blocks showing fractal features, various algorithms have been developed using the C++ computer programming language. The algorithm formulating the generation process operates top-down. Fractal approach was formed by means of Archimedes’ ‘Midpoint Displacement Method’. The developed program, by using the ‘Direct X’ (code) for every fractal dimension, creates an animation which is formed by the revolving of the blocks around themselves. With the aim of increasing the effect of the blocks, which forms the solution alternatives, various colours have been highlighted in order to form contrast, light and shade. In this way it is possible with the animation to observe more clearly the emergence of the fractal concept. The

Ework and ebusiness in architecture, engineering and construction

1058

developed algorithms, as in the algorithms for the generation of the settlement, have been executed by applying the fractal value obtained from the Kayakoy or different values. As an initial form a cube has been used. The generation process begins by locating the cube and proceeds by applying the fractal dimension to it. By way of forming 125 (5×5×5) groups of these cubes, block formations having fractal values from 1.0 to 1.9 have been created. In Table 1, it can be seen that as fractal value increases, the cubes create a more complex form, but as fractal value decreases, the cube group, by being less broken up, creates forms which can be defined by Euclidean geometry. With the aim of applying the fractal value belonging to the existing architectural pattern, the form of a unit was examined, and by means of changing fractal dimension, different alternatives were produced. The original spatial configuration of this unit was examined in the context of the forms which would appear, by means of changes in fractal value from 1.0 up to 1.9. At a fractal value of 1.0, the unit preserves its original block effect. As fractal value is increased, so the block activity of the unit increases (Table 2), (Table 3). The generation process describes how to derive one compositional configuration from other forms with different dimensions which can be generated by changing fractal dimensions. In the generation of three-dimensional forms, the number of cubes on the x, y and z axes can be defined parametrically. These parameters have been selected as 3, 5 and 7, and by applying these values to the x, y and z combinations, the forms shown in Table 4 have been generated. In this approach, fractal dimension is constant. The forms generated by changing the fractal dimension at each application from 1.1 to 1.9 are shown in Table 5.

Table 1. Form alternatives based on fractal dimensions.

1.0

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

1.9

Table 2. Generating form alternatives by changing fractal dimension belonging to the existing architectural pattern.

A computational architectural design approach based on fractals

1059

1.0

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

1.9

Table 3. Animation snap-shots based on fractal dimension 1.4.

Table 4. Fractal dimension 1.7.

3×5×7

5×3×7

7×3×5

Table 5. Fractal dimensions 1.1–1.9 for 3×5×7.

1.1

1.2

1.3

1.4

Ework and ebusiness in architecture, engineering and construction

1.6

1.7

1.8

1060

1.9

Table 6. Animation snap-shots for 3×5×7 based on Fractal dimension 1.9.

Figure 1. The structure of the CADaFED. The animation snap-shots of the form for a fractal value of 1.9 can be seen in Table 6. 3 STRUCTURE OF THE CADaFED MODEL The CADaFED (Computational Architectural Design approach based on Fractals at the Early Design) model consists of five main units:

A computational architectural design approach based on fractals

1061

• Input unit, • Shape library unit, • Generation unit, • Settlement output unit, • Animation unit. The parameters are: • Dimensions of the initial shape/number of the cubes • Fractal dimension that will be used in the generation process • Topographic data.

4 CONCLUSIONS The fractal geometry and fractal concepts which have appeared through chaos theory affect contemporary architectural understanding from different aspects. Fractal concepts, have come to be used in many ways, both consciously and unconsciously, in the field of architecture. Spatial configurations, which have been represented by constraints or rules in the abductive approach, have been represented by generative algorithms in the generative approach. In this study, by relying on the fractal dimension of an existing architectural pattern, and at the early design phase, a generative design approach has been suggested which can be used in the direction of supporting creativity in the creation of new forms. By using the fractal dimensions of elements found in a shape library belonging to the relevant architectural language, this approach may show the way to the creation of architectural forms which will ensure the continuity of the pattern. Different form alternatives can be generated by changing fractal dimension. But it is necessary to apply the functional features to the generated forms by uniting them with the context and to develop them as an architectural design product by evaluating them according to their performance requirements. The generative algorithm developed provides the possibility for the generation of a new pattern and new architectural form, by being connected with a definite architectural pattern, either dependent on or independentof it. Using digital technologies when searching for alternative forms in the conceptual design phase is a new approach based on the development of new technologies. Using digital media as design media gives the designer the opportunity to extend his/her imagination and innovations. In further research, by placing the three-dimensional form alternatives at the settlement model, harmony can be tested with the existing architectural language. REFERENCES Agarval, M., Cagan, J., 1998. A Blend of Different Tastes: The Language of Coffee Makers, Environment and Planning B: Planning and Design, vol: 25, no: 2, 205–226.

Ework and ebusiness in architecture, engineering and construction

1062

Akm, Ö., Sen, R., 1994. HeGeL-II: Heuristics and Optimization Based Search in Early Design, 7th International Conference on Systems Research, Informatics and Cybernetics, Advances in Computer-Based Building Design Systems, Ed: J.Pohl, 127–136, Baden-Baden. Baykan, C.A. & Fox, M.S. 1997. Spatial Synthesis by Disjunctive Constraint Satisfaction, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, vol: 11, 245–262, USA: Cambridge University Press. Bovill, C., 1996. Fractal Geometry In Architecture and Design, Boston: Birkhauser. Chase, S., 1999. Grammar Based design Issues for User Interaction, ACADIA’99, 198–210. Coyne, R.D., M.A.Rosenman, A.D.Radford, M.Balachandran, J.S.Gero, 1990. Knowledge-Based Design Systems, U.S.A.: Addison-Wesley. Çağdaş, G., (1996a). A Shape Grammar Model for Designing Row-houses, Design Studies, vol: 17, no: 1, 35–51. Çağdaş, G., (1996b), A Shape Grammar: The Language of Traditional Turkish Houses, Environment and Planning B: Planning and Design, vol: 23, no: 5, 443–464. Downing, E., Flemming, U., 1981. The Bungalows of Buffalo, Environment and Planning B, vol: 8, 269–293. Duarte, J.P., 1998. Using Grammars to Customize Mass Housing: the Case of Siza’s Houses at Malagueira, IAHS World Congress on Housing, Lisbon, Portugal. Flemming, U., 1987. More than the sum of parts: the grammar of Queen Anne houses, Environment and Planning B, Planning and Design, cilt: 14, 323–350. Flemming U, Aygen Z, Coyne R and Snyder J: 1997. Case-Based Design in a Software that Supports the Early Phases in Building Design in Mary Lou Maher and Pearl Pu (eds), Issues and Applications of Case-Based Reasoning in Design, Lawrence Erlbaum Associates, USA, 61– 85. Kisacikoğlu, B., Çağdaş, G., 2004. Architectural Plan Layout Generatorby Exhaustive Search: APSIS, (it will be presented ECPPM 2004), İstanbul. Knight, T., 1998. Designing a shape Grammar, Artificial Intelligence in Design ’98, J.Gero, F.Sudweeks, (eds.), Kluwer Academic Publ., The Netherlands, pp: 499. Koning, H., Eizenberg, J., 1981. The language of the prairie: Frank Lloyd Wright’s prairie houses, Environment and Planning B, vol: 8, sf: 295–323. Mitchell, W.J., 1977. Computer-Aided Architectural Design, NewYork: Petrocelli/Charter. Stiny, G., 1980. Introduction to Shape and Shape Grammars, Environment and Planning B, vol: 7, 343–351. Schmitt, G., Chen C.C., 1991. Classes of Design—Classes of Methods—Classes of Tools, Design Studies, 12, No: 4, 246–251. Tapia, M., 1999. A visual implementation of a shape grammar system, Environment and Planning B, Planning and Design, vol: 26, no: 1, 59–73. Yoon, R.Coyne, 1992. Reasoning about spatial constraints, Environment and Planning: Planning and Design, 19, 243–266.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) ©2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

APSIS architectural plan layout generator by exhaustive search B.Kisacikoglu Istanbul Technical University, Institute of Science and Technology, Graduate Program of Architectural Design Computing, Istanbul, Turkey G.Çağdaş Istanbul Technical University, Faculty of Architecture, Istanbul, Turkey ABSTRACT: In this paper we deal with space planning in architectural design. APSIS (Architectural Plan layout generator by exhaustive Search of constraint conformity In the design Space) that we have developed is an automated system that exhaustively searches grid scaled architectural plan layouts conforming to given constraints that specify layout problems at one floor level. The search organization that dimensional layout possibilities are enumerated firstly and layout topology is searched secondly, is different than known methods in literature. This has become a test subject in our research to explore the disadvantages or advantages by experimenting and to discuss the validity of this method. An interactive layout design model that the problem specification is gradually under control of the designer is proposed for APSIS considering the complex aspects of space planning as a design problem that will be described in this paper. In each phase of this gradual process, the task of APSIS is to automate layout generation and form a feedback report to let the designer make decisions by revising the constraints.

1 INTRODUCTION It is well known that most design problems are characterized as ill specified and building computer programs that deal with such domains is a tough challenge. The most common approach to make effective computer systems in design is building programs to support the designers in various sub problems that algorithmic search or case matching is possible. In this study, space planning in architectural design is determined as a sub problem that can be facilitated with an automated system that performs an exhaustive algorithmic search. The layout design model that we will propose here involves an interactive and gradual process considering the need of user guidance in problem specification. In each phase of this process, the user tries to specify the problem in terms of constraints and APSIS (Architectural Plan layout generator by exhaustive Search of constraint conformity In the

Ework and ebusiness in architecture, engineering and construction

1064

design Space) that we have developed automates the layout generation and supplies feedback to the user. The exhaustive search of APSIS generates all grid plan layouts that satisiy all constraints specifying layout problems at one floor level. The search organization is different than known methods in literature. Since the search is performed on a grid system, we found out that it is also possible to start with dimensioning and considering the topology later. Designing this algorithm with such a search organization, which is logically less efficient, was one of the goals of our research to reach a design space of layout design by approaching the problem from a different point of view. Another goal was to experiment the use of this search in layout design to explore the advantages or disadvantages. We will describe briefly how this is achieved and validity of this method will be discussed as a result. This paper will also report an ongoing research of forming a feedback report by a heuristic based reasoning. 2 SPACE PLANNING IN ARCHITECTURAL DESIGN 2.1 Space planning as a design problem In this paper, space planning in architectural design is understood as the arrangements of rooms in a building. These arrangements may involve determination of rooms’ topological relations and dimensions in 2D or 3D. Space planning cannot be defined as an independent problem in the whole architectural design process. All design criterions about building functions, relations of these functions, circulation, environment, form of the building, cost, structural system, site constraints, isolation, acoustic etc. are considered with an optimizing approach in the design process and the requirements of space planning may arise from any of these criteria. These requirements that the designer puts forward may be lacking, uncertain and contradictory at the start of the design process. Space planning is also a highly combinatorial problem. The solution space may differ greatly with a simple change in the problem specification. While designers optimize the satisfaction of design requirements to find layout solutions, they obliquely eliminate unsatisfied requirements and may also explore new requirements. The designers’ priorities are often subjective so they may be satisfied with different solutions. As described above, space planning process involves a progression in problem specification as satisfying solutions are reached so the problem specification needs to be interactive and under the guidance of the designer in a computer model. An automated system to be used in this process should be formulated to give adequate feedback to let the designer understand what is happening and why (Baykan 2003). 2.2 Space planning in literature Several computer models have been developed to solve space planning problem in architectural design. When these models are examined, a common approach will be noticed that the systems start with searching layout topology. Some of these models are presented below.

APSIS architectural plan layout generator by exhaustive search

1065

Mitchell, Steadman & Ligget (1976) introduced using generate and test strategy to produce topological layouts. Dimensioning was a secondary operation in this model and it is interpreted as an optimization problem. In this model, the generative algorithm developed by Steadman (1973) that can reach exhaustively all possible and distinct dissections of rectangles was coupled with a testing procedure of constraints. LOOS also could exhaustively generate topological layouts that are represented similarly to rectangular dissections by using a hierarchical generate and test method in which the hierarchy was defined by heuristics and constraints. (Flemming et al. 1992) Yoon & Coyne (1992) introduced reasoning with constraint propagation method that a topological layout is derived through the direct manipulation of constraints. This method involves a constraint directed heuristic search. HeGeL also automated the generate and test cycle of topological search and the problem structuring cycle was simulated with user input (Akin et al. 1992). With HeGeLII, an optimization module is coupled with HeGeL’s generate and test cycle to select best solutions according to cost as an optimization criteria (Akin & Sen 1994). In WRIGHT, the problem was formulated as a constrained optimization problem and it used disjunctive constraint satisfaction method that is a form of constraint directed heuristic search (Baykan & Fox 1997). ARCHiPLAN also could reach the solutions at a topological level by using topological enumeration heuristics. The perspective was to select best layout solutions with the help of an optimization module that the user can specify an optimization criterion (Medjdoub & Yannou 1998). SEED project that is developed in CMU to provide computational support for the early phases in building design has a layout module that generates schematic layouts for an architectural design brief that the user forms with the help of an elaborate user interface (Flemming et al. 1997). 3 THE AUTOMATED SYSTEM APSIS 3.1 The system The components that form the system of APSIS are shown in Figure 1. These components and the usage process of the system will be described briefly in this section. 3.2 The design process Considering the complex aspects of space planning in architectural design that are described in section 2.1, we decided that this problem could be achieved with computer support in an interactive process that the problem specification is gradually under control of the designer. In each phase of this process, the computer’s task is to automate layout generation and obtain adequate feedback to help the designer to make decisions. APSIS is developed to support such a design process as shown in Figure 2.

Ework and ebusiness in architecture, engineering and construction

1066

Figure 1. The system schema of APSIS. In the usage process, the user specifies the problem initially and starts the generation. The system supplies some feedback to the user during and after the generation. The user also obtains some feedback by examining the generated layouts. Then the user revises the problem specification according to these feedbacks and starts another generation. Such phases repeat until the most satisfying solution set is generated and the most convenient problem specification is formed. And the final layout design is selected from the last solution set. 3.3 Representation of layouts APSIS generates the layouts on a grid coordinate system. Grid system is preferred in order to ease the representations and manipulations of the constraints in computer environment. Grid system is also helpful for designing the structural system but it highly bounds the form of the layouts. The distance between grids is set as 0.6 m, which is a modular length in architecture concerning furniture design or human dimensions. A room’s location is represented with upper left (x1, y1) and lower right (x2, y2) coordinates as shown in Figure 3 and a layout or partial layout is represented with the locations of the rooms on the coordinate system. The rooms never share a used space in the layouts that are generated by APSIS. In other words, overlapping is restricted.

APSIS architectural plan layout generator by exhaustive search

1067

Figure 2. The design process by using APSIS.

Figure 3. Locating a room on the grid coordinate system of APSIS.

3.4 Problem specification In APSIS, an architectural design brief is defined by entering the rooms and after this, the layout problem is specified in terms of dimensional and topological constraints. In this first version of the system problem specification is not widely optional, e.g. construction site is restricted with rectangle shape, logical relations such as ‘or’, ‘and’ can not be defined between constraints and there is no priority option to let the algorithm make an optimization of constraint satisfaction.

Ework and ebusiness in architecture, engineering and construction

1068

3.4.1 Dimensional constraints One can define dimensional constraints of the rooms and the construction space in a rectangular format in APSIS. The inputs for the rooms are minimum area, maximum area and minimum side length. These inputs are considered in a minimized format to define the whole set of rectangular dimensional possibilities on a grid system. As soon as these inputs are entered, dimensional possibilities of the room are calculated. An example of this calculation for 0.6m grid system is shown in Table 1. The inputs for the construction site are x and y lengths. In order to satisfy this constraint, the generated layout’s or partial layout’s x and y lengths must be up to the construction site’s x and y lengths. 3.4.2 Topological constraints One can define adjacencies, connections and orientations of rooms as topological constraints in APSIS. If access is required between two rooms with related functions then these rooms are specified as connected. Two rooms with related functions can also be specified as adjacent when access is not required.

Table 1. An example of a room’s dimensional possibilities. Minimum area

12 m2

Maximum area

16 m2

Minimum side length

3m

Possibility no.

x length (m)

y length (m)

Area (m2)

1

3.0

4.2

12.60

2

4.2

3.0

12.60

3

3.6

3.6

12.96

4

3.0

4.8

14.40

5

4.8

3.0

14.40

6

3.6

4.2

15.12

7

4.2

3.6

15.12

APSIS architectural plan layout generator by exhaustive search

1069

Figure 4. Adjacency or connection possibilities between two rectangle rooms.

Figure 5. Full side connection possibilities between two rectangle rooms. In Figure 4, adjacency or connection possibilities for two rectangle rooms are shown. A special connection specification of APSIS is full side connection, which means that two rooms are connected enables formation of L, T, U shaped rooms or any other shaped rooms that are composed of rectangles. Possible full side connections between two rectangle rooms are shown in Figure 5. A room’s orientation generally defines that transparency or access is required to a certain direction so the user selects the directions to specify orientations of rooms. If more than one direction are selected then the system sets ‘or’ logical relation automatically between them. The system will check if the room is located on required side of the layout in order to satisfy the orientation constraint. 3.5 The algorithm The method used in the algorithm of APSIS can be named as exhaustive search of constraint conformity in the design space. With this search method, APSIS finds the whole solution set of the specified layout problem, which is a part of the design space bounded by the constraints. Different than referenced computer models in Section 2.2, dimensioning of layouts comes before the search of layout topology in the algorithm of APSIS. In order to perform an exhaustive search with this method, dimensioning of the layout is done by a procedure that can reach all combinations of the rooms’ dimensional possibilities to enumerate dimensional layout possibilities. In Figure 6, forming the dimensional layout

Ework and ebusiness in architecture, engineering and construction

1070

possibilities of an example with four rooms is shown in which 150 (5×3×2×5) possibilities can be formed. This operation is done in a cycle with layout generation (Fig. 1). Layout topology is searched after forming each dimensional layout possibility. So dimensioned rooms take place in the topological search and as a result, layouts that are in the form of scaled architectural plans are generated.

Figure 6. Forming dimensional layout possibilities of an example with four rooms. Generate and test strategy is used in the development of this topological search of APSIS that is similar in few aspects and dissimilar in others to human designer’s sketching. First of all, considering dimensions while searching layout topology is similar but the way that it is handled is dissimilar, because human designers do not consider all dimensional layout possibilities while sketching. Sketching involves an experimental process of optimizing the satisfaction of requirements to reach satisfying solutions. While making layout sketches, designers try different topological arrangements and evaluate the satisfaction of requirements according to their subjective priorities. In these trials, designers follow an intuitive order that comes from their logic and experience. In Figure 7, the flow diagram of topological search algorithm of APSIS is shown. This search can also be defined as the process of generating layouts and collecting feedbacks (Fig. 1). Similarly to sketching, the topological search of APSIS also tries and evaluates but dissimilarly, the evaluation criterion is satisfaction of all constraints. The system

APSIS architectural plan layout generator by exhaustive search

1071

generates the layouts by placing the rooms sequentially in an order that is determined by heuristic rules. While determining this placement order, a base room is selected for all the rooms except the room that will be placed first. A room must be connected with its base room and the base room must be one of the rooms that will be placed beforehand. Base rooms’ function is to determine the location of the rooms that will be placed. Candidate locations of a room are possible locations that a connection can be made with its base room and these locations follow a clock wise direction around the base room as shown in Figure 8.

Figure 7. The flow diagram of topological search algorithm.

Ework and ebusiness in architecture, engineering and construction

1072

Figure 8. Candidate placement locations of a room. The generation steps coordinator (GSC) determines the generation steps considering all possible candidate locations of rooms following the placement order. In each generation step, coordinates of a candidate location of the room that will be placed are found and the last state of the layout is sent to the testing unit (TU). TU tests all constraints concerning the placed rooms in the layout with a successive strategy that saves the search time by skipping the rest of the tests whenever one fails. If all tests are passed and all rooms are placed, the layout is sent to the solution set.

APSIS architectural plan layout generator by exhaustive search

1073

Figure 9. The search tree of GSC. In cases of unsuccessful generation steps, GSC backtracks and skips the rest of its sub steps in the search tree that is shown in Figure 9 and the search continues until all placement possibilities are exhausted. So, the order of generation steps that is determined by heuristic rules and probability calculations is also dissimilar to designers’ intuitive trial order in sketching. In Figure 9, the numbers in parenthesis represent the candidate location id’s of placed rooms until that step. Two examples of unsuccessful steps are shown with arrows and the sub steps that are skipped are shown in dashed bubbles. The topological search algorithm of APSIS has the potential to determine the constraints that bound the design space most and to form a feedback report including

Ework and ebusiness in architecture, engineering and construction

1074

advices to enlarge the solution set. This potential came within the different search organization that APSIS uses, because a deeper exhaustive search is made in a larger design space. Collecting feedbacks and forming a feedback report is not yet implemented in APSIS v.1 so this method is not experimentally proven. Theoretically, the system can derive the advices through the type and specifications of the unsatisfied constraints by using heuristic rules that can be formed logically or experimentally. In Table 2, a possible logical heuristic rule table is shown. Collecting the feedbacks operation is simply logging the number of unsuccessful generation steps caused by each constraint separately during the whole exhaustive search. With a shallow reasoning a heuristic rule can state that constraints that cause more unsuccessful generation steps bound the design space more but this cannot be a fair comparison. Some type of tests may naturally fail more than others considering the search organization so the constraints must be compared separately according to the type of test. Also, some constraints concerning some of the rooms will be tested more than others considering the room placement order and backtracking (Fig. 9), so the feedbacks must be manipulated by heuristic functions in order to make a fair comparison. The formulation of these heuristic functions involves an experimental process. 3.6 The user interface There are many necessary user interactions in the layout design model that we propose. The user interface of APSIS v.1 is developed in a minimized format and these necessary interactions are handled through three interface modules. These are constraints interface, generation interface and a graphical interface. Constraints interface is composed of menus that a layout problem can be specified. The room constraints menu is shown in Figure 10. The user can add, change or erase the constraints and rooms through this interface while making an initial problem specification or revision. This interface also warns the user in situations that immediate assistance is necessary, e.g. if the minimum side length is long for the area range or if the aspect ratio is smaller than 1/30 while dimensional constraints of a room are being entered.

Table 2. Heuristic rule table for system’s advices. Type of test

Constraint specification

Advice

Overlapping

Room1: The room that overlaps Increase the area of room1’s base room

C. Site overflow Parallel to x axis 1

Increase x length of c. site

Parallel to y axis

Increase y length of c. site

C. Site overflow Room1: The room that 2 overflows

Decrease the area of room1 Reconsider the relation of room1 with its base room

Rooms’ relations

Room1 and Room2: Related rooms

Reconsider the relation of room1 and room2

Rooms’

Room1 : The room that

Reconsider room1’s orientations

APSIS architectural plan layout generator by exhaustive search

orientations

1075

orientation is specified

Generation process is controlled through the generation interface, such as start/stop controls or on/oif toggles of animation mode. This interface also transmits the numerical progression data to the user as the generation proceeds. There is a generation report menu within this interface that the user can view all constraint specifications together in charts before starting the generation (Fig. 11). Also, this will be the interface that the feedback report can be reached. The plan layouts that are generated can be viewed with zoom and pan toggles in the graphical interface. The generation process can also be animated through this interface to increase the feedback to the user (Fig. 12).

Figure 10. The room constraints menu.

Figure 11. The generation reports menu.

Ework and ebusiness in architecture, engineering and construction

1076

Figure 12. Animation of a generation. 4 IMPLEMENTATION The automated system APSIS v.1 is coded as a console application in Dev-Pascal v.1.9 (using Free Pascal compiler v.1.0, Dev-Pascal is a trademark of Bloodshed Software). In this section, implementation of the system will be presented with an example that a one-floor house will be designed. Two phases of its gradual process will be demonstrated in detail. The constraints seen in Table 3 are entered as initial problem specification of the one floor house. The whole generation process lasted in 10 seconds with an Intel Celeron 1200MHz. processor. 1079 layouts were generated while searching 1536 dimensional layout possibilities. Some of these layouts are shown in Figure 13.

Table 3. Constraints of the one-floor house. Dimensional Constr. min A 1—Entrance 2—Living R. 3—Kitchen 4—WC

max A 2

7m

2

28 m

2

9m

2

2m

min L

Topological Constr. con

adj

or

2

2m 2347

N

2

5m 13

E

2

3m 12

4

–

2

1m 1

3

–

8m 30 m 12 m 3m

APSIS architectural plan layout generator by exhaustive search

5—Parent R. 6—Child R. 7—Room Hall 8—Bathroom

1077

14 m2

16 m2

3m 7

–

2

2

3m 7

–

2

1m 1568

–

2

2m 7

–

10 m

2

2m

2

7m

12 m 3m 8m

Figure 13. Some of the layouts that APSIS generated with the input data in Table 3. After several revisions in the problem specification another set of constraints is formed as shown in Table 4. These revisions are summarized below: One bathroom is split into two separate private bathrooms for the child and the parent room. A dining room that is full side connected to the living room is added. The room hall’s function is changed to a bigger hall that is used for main circulation and WC’s adjacency with the kitchen is changed to bathroom adjacency.

Ework and ebusiness in architecture, engineering and construction

1078

The generation after the revisions in Table 4 lasted in 60 seconds and 301 layouts were generated while searching 4608 dimensional layout possibilities. Some of these layouts are shown in Figure 14.

Table 4. Constraints of the one-floor house after revisions. Dimensional Constr. min A 1—Hall 2—Living R. 3—Kitchen 4—WC

max A 2

min L 2

Topological Constr. con

adj

7m

8m

28 m2

30 m2

5 m 7-fs 10

3

E

2

2

3m 17

2

–

2

1m 1

8

–

2

9m

2

2m

2

12 m 3m

2 m 3 4 5 6 10

or –

5—Parent R.

14 m

16 m

3m 18

–

6—Child R.

10 m2

12 m2

3m 19

–

2

2

1 m 2-fs. 3

–

2

2m 5

49

2

2m 6

8

2

2m 12

7—Dining R. 8—P.Bathr. 9—C.Bathr. 10—Entrance

9m

2

6m

2

4m

2

4m

10 m 7m 5m 5m

–

N

APSIS architectural plan layout generator by exhaustive search

1079

Figure 14. Some of the layouts that APSIS generated with the input data in Table 4. From the last solution set, we selected the plan at the top left corner as the most satisfying alternative. The holes that took shape in this plan can be used as very functional wardrobes and overall shape of the plan also looks better because of the symmetry. 5 CONCLUSION It is proven with examples that reaching a layout solution is possible with the design model proposed for APSIS. The advantage of using an automated system that generates layouts exhaustively is that the designer can consider much more alternatives than conventional sketching method because space planning is highly combinatorial and it is often impossible to produce all possible layout designs with human search capacities.

Ework and ebusiness in architecture, engineering and construction

1080

Another good part of the developed algorithm is that the automated system generates dimensioned plan layouts, in other words it generates almost finished architectural plans. The purpose of this is to leave least correction to the designer. But with the exhaustive search mechanism that reaches all possibilities, many of the generated layouts in a solution set can be dimensional variations of each other and some of the layouts can be very similar with very small changes in dimensions. Also, some layouts can contain unspecified spaces that are called as holes. These can be obstructing matters for the user while examining the solution set of a generation. This problem can be solved by filters that will help the user to sort or group the solutions according to some criterions such as shapes, areas, topology etc. One disadvantage of the algorithm is the length of search time when there is a huge number of dimensional layout possibilities. This number may be more than 1010 in a layout problem that is specified with 10 rooms that entered area ranges bring out more than 10 dimensional possibilities for each. Essentially, the algorithm of APSIS is designed to handle infinite numbers of dimensional layout possibilities without any memory overflows but it takes too much time to finish the exhaustive generation although it is very efficiently programmed to make the fastest topological search. As a result, the search organization that dimensioning comes before considering topology is less efficient because a deeper exhaustive search is made in a larger design space to find solutions that quality is not much superior to other systems. Despite this fact, the ongoing research of collecting feedback data during the whole search and forming a feedback report as a result can be seen as a potential that came within this search organization. REFERENCES Akin, Ö., Dave, B. & Pithavadian, S. 1992. Heuristic Generation of Layouts (HeGeL) Based on a Paradigm for Problem Structuring, Environment and Planning B: Planning and Design: 33–59. Vol. 19. Akin, Ö. & Sen, R. 1994. HeGeL-II: Heuristic and Optimization Based Search in Early Design, Preconference Proceedings of Advances in Computer Based Building Design Systems: 127– 136. Symposium of the 7th International Conference on Systems Research, Informatics and Cybernetics, August 15–21, Baden-Baden, Germany. Baykan, C.A. & Fox, M.S. 1997. Spatial Synthesis by Disjunctive Constraint Satisfaction, Artificial Intelligence for Engineering Design, Analysis and Manufacturing: 245–262. Vol. 11, USA: Cambridge University Press. Baykan, C.A. 2003. Spatial Relations and Architectural Plans, In Bige Tuncer, Saban Suat Ozsariyildiz & Sevil Sariyildiz (eds), E-Activities in Design and Design Education: 137–146. Paris, France: Europia. Flemming, U., Baykan, C.A., Coyne, R. & Fox, M.S. 1992. Hierarchical Generate-And-Test vs. Constraint-Directed Search, Artificial Intelligence in Design`92:817–838. Boston, USA: Kluwer Academic Publishers. Flemming, U., Aygen, Z. Coyne, R. & Snyder, J. 1997. Case-Based Design in a Software that Supports the Early Phases in Building Design, In Mary Lou Maher & Pearl Pu (eds), Issues and Applications of Case-Based Reasoning in Design: 61–85. USA: Lawrence Erlbaum Associates. Medjdoub, B. & Yannou, B. 1998. Topological Enumeration Heuristics in Constraint-Based Space Layout Planning, Artificial Intelligence in Design`98: 271–290. The Netherlands: Kluwer Academic Publishers.

APSIS architectural plan layout generator by exhaustive search

1081

Mitchell, W.J., Steadman, J.P & Liggett, R.S. 1976. Synthesis and Optimization of Small Rectangular Plans, Environment and Planning B: Planning and Design: 37–70. Vol. 3. Steadman, J.P. 1973. Graph theoretic representation of architectural arrangement, Architectural Research and Training: 161–172. Vol. 2. Yoon, K.B. & Coyne, R.D. 1992. Reasoning about Spatial Constraints, Environment and Planning B: Planning and Design: 33–59. Vol. 19.

eWork and eBusiness in Architecture, Engineering and Construction–Dikbaş & Scherer (eds.) ©2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Architectural parametric design and mass customization Sander Boer & Kas Oosterhuis ONL architecture, Rotterdam, Netherlands ABSTRACT: One building, one detail. The particular detail is the invention that makes the innovation possible, being purposely parametric. We call this File-to-Factory; it is part of an intentionally imploded information stream that connects the virtual 3d model with the actual building. By means of a process description of our design of ‘the web of North Holland’ we argue that not only it is possible to build a construction that describes a double curved shape, but it is possible to do it with regular construction means and regular 3d programs with regular building budgets.

1 DESIGN CONCEPTION

For the dutch province of North Holland we designed a pavilion for the world horticultural exhibition ‘floriade’ 2002. The pavilion is a spaceship, a closed autonomous object tha t landed on the floriade. Architecturally there is no distinguishable difference between wall, floor nor ceiling. The design was based on a topological surface that governs the logical esthetic continuity of the shape. The specific shape of the surface came about in a design process which combined milled physical models of the computer model with again computer modelling of adaptations to the milled models to attain a good space for its programme as well as introducing our own rigorous styling requirements. During this process a clear vision arose of the concave/ convex dynamics and the the shaping lines, the folding lines that fade in and fade out of the shape. We described the styling requirements in a number of shaping rules of the design. It was important to describe the design not in mass, but in a number of design rules and guidelines since its internal programme was still to change. For this flexibility in a single autonomous shape the construction needs to follow the shape in a non-hierarchical way, adapting its local performance to local stresses.

Architectural parametric design and mass customization

1083

2 TOPOLOGICAL CONSTRUCTION GRID To control the shape and the look of the design a NURBS surface was created. NURBS is an acronym for Non-Uniform Rational Bezier Splines, a container for a number of polynomial algorhithms. Its use is widespread in the design and character animation industry. In architecture the use of these techniques involves a genuine paradigm shift away from the use of two dimensional plans and sections. Simply put, one cannot build a double curved surface using plans and sections, because every plan and every section is different at different section planes. The logical reaction is to use the NURBS surface as the plan by having it govern the integrity of the construction. Expanding on the conventional paradigm of a construction grid we mapped a triangular grid with the internal inegrity of an icosahedron on the NURBS surface. We chose the icosahedron system for a number of reasons, but mainly because like the design, it is a closed system. An icosahedron is a 20-faced polyhedron. Each point connects to either five or six other points. This grid can be refined by subdividing each of the main twenty faces into smaller triangles. After a number of excercises we decided that subdividing each main triangle into 36 smaller triangles (i.e. subdivide each edge into six edges) was the most efficient in terms of number of details and the maximum dimensions for each triangle for the cladding.

Illustratration 1. NURBS surface of the design.

Ework and ebusiness in architecture, engineering and construction

1084

Illustration 2. Mapping of a constructive grid based on an icosahedron In hindsight one can argue that the choice for a 3d construction grid based on an icosahedron is purely arbitrary, since there exist a number of tesselating algorithms that can take into account the curvature of the surface and look very intelligent in doing so, but these algorithms are focused solely on approximating double curved surfaces into triangular meshes for rendering purposes only. As of yet there exist no NURBS tesselating algorithms that base their distribution of the triangles not only on curvature but also incorporate meta data like strength of a given profile and incorporates environmental conditions like gravity, wind-direction and other load bearing conditions. Therefore we invented a tesselating system of our own and found that the icosahedron provided us crude but efficient means for fine-tuning cost-efficiency and regularity in the details. Cost-efficiency can be controlled by the degree of subdivision of the main twenty faces and because of the internal integrity of the icosahedron, each point connects either five or six other points. 3 INVENTING A DOUBLE CURVED CONSTRUCTION In architecture irregular surfaces proved to be bother-some to build and strategies to build them were often based on layers. For example a crude approximation of the shape is constructed for instance in steel and with a number of cladding layers this crude approximation would be smoothened. Obviously this approach lacks control over the shape and it is costly for it needs multiple layers of construction, secondary construction

Architectural parametric design and mass customization

1085

and cladding. A more precise method is the creation of customized molds for every segment of the building, however, this concentrates its efforts primarily on the cladding, a construction is still needed. Another strategy is projecting one or more regular grids over the shape, like one would slice a loaf of bread, although this approach results in perfectly manageable constructive ribs that can be manufactured relatively easily, it is only viable for tube-like constructions. Projection is inherently flawed for closed irregular surfaces because in its projection vector it introduces a form of anisotropy in its construction, this means the building construction favors a certain direction over others. We decided that we wanted to build the building only once, meaning that creating molds was out of the question, the shape we wanted to end up with needed to be present in the main construction. With the introduction of the construction grid based on an icosahedron we already dedicated ourselves to an approach that is linked directly to a NURBS surface, we decided to create a construction that is capable of describing this irregular surface directly and be isotropic. To do this we added vectors to the construction grid that are oriented perpendicular to the surface called normal-lines. These lines are used to orient the construction detail. However, a challenge was presented when creating a constructive connection between two non-parallel lines. Using a tubular construction was considered, but soon proved too costly. However, during a meeting with Henk Meijers of Meijers staalbouw b.v., a novel idea struck home when we realised that one could use folded plates. The idea is simple, when one needs to connect two points with a construction, one could use a simple flat plate, but when one also needs to make a transition from one initial orientation to the next, one can fold the plate over a diagonal. The innovation of this idea might not be immediately apparent, but this simple idea allows us to create a construction that describes a truly double curved surface. First, when connecting two points and their respective orientations, one folds the plate. In doing so one effectively creates two triangles each in their respective planes, joined at the diagonal. The top triangle is described by the diagonal, one of the two orientations and a line connecting the two points of the point-grid on the surface. This line can be straight, creating a construction that is polygonal, but, since it connects two points that are positioned on a surface, this connecting line can also follow the surface one to one.

Ework and ebusiness in architecture, engineering and construction

Illustration 3. Double-curved surface with a point grid mapped.

Illustration 4. Point grid with their respective normal-lines.

1086

Architectural parametric design and mass customization

1087

The same is true for the bottom triangle, but this triangle doesn’t connect two points on the surface, but an offset (in our case an offset inward) of the two surface points over their respective orientations. This line could also follow a second surface that was ofsetted from the main surface, but in case of the web of North Holland pavilion we chose to keep things as simple as possible and draw this line as a straight connection. Thus the resulting construction is exactly following a double curved surface on the outside, while being polygonal on the inside. To illustrate the above I reconstructed the system on an arbitrary irregular double curved surface: Subsequently this system was modelled using the NURBS surface of the design whilst following the construction grid that was mapped on it. The result is a construction that with its outer fiber precisely describes an irregular double curved surface, effectively being a double curved construction.

Illustration 5. Folded plate connecting two grid points, notice the surface curve of the top triangle.

Ework and ebusiness in architecture, engineering and construction

Illustration 6. Three folded plates connect into a constructive triangle.

1088

Architectural parametric design and mass customization

1089

Illustration 7. 3d model of the entire construction of the design (including two small interior volumes).

4 CONSTRUCTION PARAMETERS As a construction this system allows for a number of variables to change as it needs to adapt for local stresses. The concept of the construction is that it is nonhierarchical, which means that in essence there is no intrinsical difference between any of the construction elements like the ones found in a standard construction of girders, beams and floor-joists. Every element is only differentiated in terms of strength, this is accomplished in differentiating the parameters that account for its strength. A number of parameters account for the strength of the construction: 1. Point distribution: the distribution of the point-grid can be adapted to concentrate more points in an area that receives more stress, resulting in less span for a single plate and more mass per square meter. 2. Thickness: each plate can vary its thickness, even though its has been argued that applying flanges reinforces the plate more in relation to the resulting weight, application of the flanges involves manual labour and in the end these relatively ‘dumb’ kilos of steel proved to be more cost-efficient. 3. Offset: every point of the surface point-grid is offsetted a certain distance, this can be varied resulting in larger plates. Unfortunately we were unable to find a constructor willing to vary all three respective parameters on a short notice, mostly this was because an approach like this -varying

Ework and ebusiness in architecture, engineering and construction

1090

dimensions and distributions- calls for an interating calculation that converges towards a solution as opposed to a construction hierarchy that calculates from the top down. After much deliberation we found the constructor willing to vary one parameter; the thickness.

Illustration 8. Example construction with offset parameters highlited.

Architectural parametric design and mass customization

1091

Illustration 9. Close up of example construction with changed interior offset parameter dialog.

5 MASS CUSTOMIZATION The main concept behind a construction based on folded plates is that plates can be cut exactly and can be folded exactly in one simple workflow. Any measure taken to disrupt the simplicity of the workflow like the flanges mentioned earlier has serious implications for the cost-effectiveness. The bulk of the intelligence needs to be concentrated in the pre-manufacturing phase to eliminate details. We avoided solving problems by adding solutions and invested in creating one detail that solves all problems.

Ework and ebusiness in architecture, engineering and construction

Illustration 10. Isometric view of the 3d construction model with all the elements coded and indexed by the autolisp routine.

Illustration 11. Close up of an element indexed by the autolisp routine. In red is its final line for the cutting machine, its unique code is D2H6, its folding degree is 176 degree (i.e. 4 degrees), in the lower left corner is a textbox with the real life coordinates of each of the four corners of the plate.

1092

Architectural parametric design and mass customization

1093

We visited the workshop of the steel manufacturer and we found that the machines that cuts the steel is fed a closed line that can be created with any drawing program. Also, the fold of the plate is but a single parameter; a degree. As mentioned earlier we already invested a lot of thought in simplifying the workflow by sublimating the performance of the construction into parameters without changing the integrity of the solution. With this, what needed to be done is index these parameters and feed them to the workflow. Specifically this meant taking the 3d model of the construction, decide on how the plates are connected, measure the fold of each plate and create an outline of each plate in its unfolded state.

Illustration 12. The cutting machine in action, it just finished the plate of illustration 11.

Ework and ebusiness in architecture, engineering and construction

1094

Illustration 13. Primary assembly occurred in the workshop of the steel manufacturer. We decided on a simple bolted connection with welded connection plates. At every point five or six plates are joined, the 3d model is created with zero thickness, but when a plate is given thickness it is impossible to join six of them in the same point. To tackle this we decided on an arbitrary distance of five centimeters that every plate stops before a point. This distance proved to be enough for every point to give way for the connecting plates and the bolts. This distance is also incorporated in the 3d model by creating a cutting line in every platte in 3d so now there exists a 3d model of every element with the real dimensions in the real location. At this stage one could say the building already exists, all that needs to be done is build it. And that is what we did. I wrote an autoslip routine that takes every folded plate in the 3d model, assigns a unique code to it, unfolds it, measures its degree of folding and the coordinates of every point relative to a common orthogonal system in real life units.

Architectural parametric design and mass customization

1095

Illustration 14. final assembly on the site. The unique code is necessary because every plate is different. The unfolding is necessary for the generation of a closed line that is fed directly to the cutting machine, this is the core of what we popularly tend to refer to as File-to-Factory. The folding degree is obviously needed for folding the plate; every plate has a unique folding degree. The coordinates are necessary to be able to monitor and measure the assembly of the plates in real life with for instance a laser measuring apparatus like total station. 6 CLADDING This pavilion was designed to be open-air, meaning that in essence the construction is open and that rain would essentially fall through it. In respect to cladding this building, things were pretty simple in terms of insulation and waterproofing. However, we invested in creating a construction that already describes the shape exactly, therefore the cladding must be able to follow this shape with a minimum of processing. I stated earlier that we wanted to build this building only once, this statement was born when we attendended a lecture on exploforming, a process that uses a controlled explosion to force a sheet of metal into a mold. We realised that with creating a mold, one is building the building more than once and throwing half of it away. Prior to the design of this pavilion we conducted a small study of the material ‘hylite’, an aluminium laminate produced by the corus group that consists of aluminium and polycarbonate. It has the look of aluminium, but the flexibility and pliability of a polymere.

Ework and ebusiness in architecture, engineering and construction

Illustration 15. A triangle of hylite fitted on a construction triangle of three independent curves.

Illustration 16. 3D model of the hylite panels with the construction showing.

1096

Architectural parametric design and mass customization

1097

Illustration 17. Hylite panels as fixed to the construction. We found the a flexible material will let itself be fitted on a triangle of three spatial curves in a form of pseudo double curvedness.

Illustration 18. Specific view to illustrate the effectiveness of the application of the hylite.

Ework and ebusiness in architecture, engineering and construction

1098

Although outside the scope of this paper, what happens is that the triangle will ply itself into a subdivision of triangles. Again, for quick assembly on the site we modelled every hylite triangle and unrolled it so a waterjet cutter could cut the individual plates. It is interesting to note that no one was capable of unrolling essentially real double curved triangles into a cutting line and to some extend account for the difference of the real double curvedness of the 3d model and the pseudo double curvedness of the hylite panel. Except for a company that specialises in tensile structures of cloth. They have software that is able to stretch, unstretch and unroll flexible materials. 7 CONCLUSION With the pavilion for the web of North Holland we reaffirmed our strong beliefs acquired by previous projects that one can gain a maximum design freedom and keep the budget in check by gaining control over a system of similar, but different elements. A number of techniques can be determined that make this possible: 1. File to Factory: A construction process is greatly simplified by concentrating intelligence in the design of the construction so it solves all problems instead of just one (and agregating complexity). 2. Mass customization: An irregular shape can only exist by the grace of irregular elements, therefore control over mass-customization greatly increases design freedom. 3. Parametrization: Ideally, in a mass-customized solution more parameters can be found than those that account for shape alone. These can be utilized to optimise the design. We mentioned earlier that an iterating construction calculation program can converge towards a construction that doesn’t only have variable thicknesses, but also variable heights and an optimal point distribution. Similarly, in a design process parameters can change in accordance to design requirements and iterative scripts can be written to accommodate very specific demands. For instance a script can be written to create a web of North Holland pavilion with the exact volume of 1000 m3.

Illustration 19. Screengrab of the soundbarrier/cockpit 3d model, the

Architectural parametric design and mass customization

1099

cockpit building is the bulge in the middle.

Illustration 20. Rendering of the cockpit building, notice the fluid transition between the acoustic barrier (dark) and the building itself. 4. Design control hierarchy: In this specific pavilion the shape is described in a single NURBS surface, essentially all that follows will refer to this surface. A NURBS surface is created using NURBS lines, keeping this creation link intact yields control on a higher level, by changing the line, the surface changes and the entire system changes. Primarily for designers this notion is paramount, especially when incorporating an interior design in this system, a hierarchy of control over the design is necessary. In the meantime we now have two projects in initial realisation phase that have been designed with the above in mind: the cockpit building and the sound barrier.

Ework and ebusiness in architecture, engineering and construction

1100

Illustration 21. Screengrab of the soundbarrier construction, this construction is generated by the steel constructor (meijers staalbouw bv.) based on geometry we provided. The Cockpit building is part of a fluid design of the sound barrier, to accommodate the transition from the one to the other the design control hierarchy proved to be essential, both projects share the same outlines, but differ in construction principle. Construction is based on a streamlined File-to-Factory process described earlier. This is partly because the construction is polygonal, although the design is curved, but this greatly improves our choice in building materials and construction principles. We are proud to mention that even though the cockpit is designed to be a showroom for cars of the most exclusive sector, its price is below $$ 750 per square meter, which is the equivalent of regular everyday showroom. Prof. Kas oosterhuis M.Sc is professor at the faculty of architecture University of Technology Delft, director of the Hyperbody Research Group and principal of ONL [oosterhuis_lenard] office for architecture, arts and research, Rotterdam. e-mail: [email protected] http://www.oosterhuis.nl/ http://www.hyperbody.nl/ Sander Boer M.Sc. is currently employed at ONL as an architect and programmer. e-mail: [email protected] http://www.oosterhuis.nl/ All images are coprighted by ONL, except for illustrations 13 and 14; courtesy of Berry van Heeren, Meijers Staalbouw bv. eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

A model for hierarchical floorplan geometries based on shape functions G.Zimmermann Department of Computer Science, University of Kaiserslautern, Kaiserslautern, Germany G.Suter Department of Building Physics, Vienna University of Technology ABSTRACT: We introduce a model for hierarchical floor planning that uses shape functions for rapid and flexible solution of space aspect ratio and area constraints under discrete and continuous modifications. The shape function approach is extended to allow for certain non-orthogonal shapes as well.

1 INTRODUCTION Computational support for the generation and modification of floor plans has been an important research focus in the architectural and VLSI (Very Large Scale Integrated circuits) design domains. Design environments have been developed that support a variety of design styles for layout generation, ranging from automated appraisal of manually generated layouts, incremental generation and selection of partial solutions, to the exhaustive, automatic generation of layout alternatives for a given set of constraints (see, for example, Pfefferkorn 1971, Eastman 1973). The theoretical aspects of layout generators in the latter system category are well-understood (Flemming 1978). Typical layout systems have a modular structure and use a generate-and-test search paradigm. Generators usually implement a floor plan representation based on the concept of dissection. Such a representation for spaces or chip cells tends to be restricted to rectangular shapes and ensures that these do not overlap. Furthermore, dissection-based representations for floor planning facilitate adjacency checks. Topological as well as geometric constraints on dimensions, areas, or aspect ratios of rectangles play an important role in filtering the number of possible solutions down to a number that is manageable for human designers. In recent years, however, attention in floor planning research has shifted from generators to the development of testers that effectively and transparently support the filtering and design navigation steps. Despite considerable efforts, computer-assisted generation of floor plans have had mixed success. While indispensable in chip design, floor planners in architectural design have not advanced beyond prototype implementations. Whereas the restriction of shapes to rectangles is probably the most important limitation, as few buildings have an exclusively rectangular or orthogonal geometry, another one concerns the potentially large number of constraints that need be entered by designers and maintained during various design stages. As the architectural design process if often highly dynamic, both design solutions as well as the constraints guiding the design process might change often and at times radically. Particularly changes that occur in successive design phases, e.g.

Ework and ebusiness in architecture, engineering and construction

1102

conceptual design and design documentation, are often difficult to maintain because different representations are used. In this paper, we address two limitations of floor planning systems in architectural design. We introduce the concept of shape functions. These are well-established in VSLI design and are particularly useful in top-down design when there is uncertainty as to the required wiring space and cell dimensions. We believe that in architectural design a similar problem exists regarding the sizing of circulation spaces, space enclosure thicknesses, and space dimensions, respectively. Secondly, we extend the applicability of shape functions to certain types of non-rectangular configurations using top-down decomposition techniques that are based on the subregion representation. 2 PREVIOUS WORK Several floor planning programs use optimization techniques to evaluate and determine geometric parameters for candidate solutions that have successfully passed tests for topological relations among spaces. Harada et al. (1995), for example, use numerical continuous constraint solution to determine exact locations, aspect ratios and areas of space rectangles. This approach may be computationally expensive, particularly in large, hierarchical layouts, where analytical area calculations need to be aggregated from leaf nodes upwards toward a root node. The computational effort for the derivation of such analytical equation systems thus appears realistic only in small problems or in situations where search is limited locally In contrast, shape functions could be particularly useful for more complex layout problems because their derivation and solution is more scalable. In the context of VSLI design, a shape function has been defined “as the lower area bound of all possible rectangles of the cell” (Otten 1983, Zimmermann 1988). A more detailed definition of shape functions and a discussion of different types of shape functions is given in the next section. Shape functions have been implemented and used successfully in VSLI design environments (Zimmermann 1988, Schurmann et al., 1992). In systems such as PLAYOUT, chip planning proceeds top-down. This is facilitated by a binary tree representation of cell configurations. Shape functions are used from the outset for area estimation, which is propagated bottom-up from terminal cell nodes to a root node. As chip planning is a highly iterative process and involves various stages to arrive at a final layout, reliable estimates for cell aspect ratios and dimensions are important to achieve an efficient design process. Wiring spaces required to connect cells, for example, are a major source of uncertainty, as a such requirements are not known explicitly until the later design stages. Similar uncertainties exist in the architectural design process regarding the allocation of circulation spaces and thicknesses of space enclosures. Both factors affect the aspect ratios and areas of the principal spaces but are usually not known at the outset of the design process. Flemming has introduced the notion of loosely-packed rectangles, which provide designers with the flexibility to introduce circulation spaces into a configuration while preserving topological relations among the principal spaces. This ensures that automated space allocation can occur independent of circulation spaces (Flermning 1986, 1989). Circulation spaces thus do not need to be specified explicitly in an architectural program but may be introduced by a designer anytime as the design matures. The

A model for hierarchical floorplan geometries based on shape functions

1103

propagation of such discrete changes in a layout requires either a partial or complete refresh of a floorplan geometry while simultaneously satisfying geometric constraints such as space aspect ratios or areas. Again, shape functions can be used to guide this process and provide rapid feedback to designers. 3 PROBLEM STATEMENT 3.1 Illustrative example To simplify the explanation of our approach, we will start with simple rectangular floorplans for one level of a building with single-level floors and constant ceiling heights. We will later show how this class can be extended. As a coordinate system we use x and y for the drawing plane, x pointing in the horizontal and, y in the vertical direction, z is the height. Let us assume the task of designing a rectangular floorplan for a given space program for eight rooms, as shown in Figure 1. Let us further assume that an initial topology is given. There are several possible ways to reach this goal. One approach starts with adding up all floor areas, multiplied with a factor for wall and circulation areas, decide on the length of one side of the total floorplan, and start with drawing the outer walls first and then try to place inner walls according to the space program and the planned topology. This will result in an iterative process in which walls have to be moved and also the topology may have to be changed to find a solution. A different approach starts with creating a floor-plan for the net areas of the space program according to the topology first and adding wall and circulation areas afterwards. This addition will increase the floor-plan size. To be able to fix the length of one side of the floorplan, a transformation from topology to geometry is required. Topological changes are possible before this transformation is made. This approach should be supported by tools. Our approach supports this under the condition that the topology can be created by dissection. We will show how circulation areas can be introduced into a topology and how the transformation from topology to geometry including wall thicknesses can be automatically performed for a given overall dimension or aspect ratio.

Ework and ebusiness in architecture, engineering and construction

1104

Figure 1. Floorplan with 8 rooms and a hallway. Numbers represent net floor areas in m2.

3.2 Dissection approach Let us continue with our example. As a first step we add up all net areas from the space program to 150 m2. With a chosen x-dimension of 15m and a height of 2.5 m we get a rectangular total floor area, shown as the enclosing wire frame in Figure 2. By successive dissection a topology is achieved, represented geometrically in Figure 2. This step needs some planning to determine the order, orientation, and position of the dissection planes. It has to be mentioned that this geometry does not have to have correct dimensions, it only gives the designer an impression of the proportions. Without changing the outer dimensions, we split circulation areas off the rooms. This step distorts the shown geometry, but does not change the intended room floor areas. Figure 3 shows the resulting topology. The choice of rooms which we split to accommodate circulation area is ambiguous and does not matter for the final result. Alternatively, circulation areas can be introduced in the same way as the spaces, leading to a somewhat different dissection, but to the same principal topology.

A model for hierarchical floorplan geometries based on shape functions

1105

Figure 2. 3-dimensional floorplan topology without circulation areas.

Figure 3. 2-dimensional floorplan topology with circulation areas. For the transformation into a consistent geometry we have to provide values for net area of all rooms, the width of all hallways, and the thickness of all walls. Also, one of the outer dimensions of the final floorplan has to be fixed. We could actually fix a dimension at any level in the partitioning tree, which would involve a slightly more elaborate but analogous procedure. In the example we chose x=15 m. This results in the floorplan in Figure 4. We can observe that the outer walls are completely assigned to one space, inner walls are split between two spaces. We also observe that the y-dimension has increased because of the additional wall and circulation areas. The reduction of this “overhead” can be a goal of experiments with changes in the topology, layout of circulation areas, or the overall aspect ratio. Also, the dimensions of individual rooms can be changed

Ework and ebusiness in architecture, engineering and construction

1106

experimentally. Rooms can also be added or deleted by additional dissections or removals. 3.3 Dissection tree One important advantage of dissection is the possible representation of the topology as a tree. This tree is the key for the proposed automatic topology to geometry transformation. Since we can generate all dissections by always dissecting one space into two spaces at one step, a binary tree results. As a root node, the undissected total volume is chosen for the sake of simplicity. If more complex assemblies of floors, outdoor areas or buildings are envisioned, the site can be chosen as a root node as well. Figure 5 shows the resulting dissection tree for the example floorplan. The nodes are represented by the numbering scheme as shown in the floorplan geometry in Figure 4 for the leaf nodes. A represents the total floorplan volume. A.1 and A.2 are the subvolumes after the first dissection. Therefore, A also represents

Figure 4. Final floorplan geometry. Numbers in the rooms are a uniquely created space identity and the net floor area.

A model for hierarchical floorplan geometries based on shape functions

1107

Figure 5. Dissection tree for the floorplan in Figure 4 as indented list. the first dissection plane. All nodes that are not leaf nodes have this twofold meaning. In Figure 5 internal nodes have either a v (vertical) or an h (horizontal) as parameter, showing the orientation of the dissection in the floor plane. The order from top to bottom has a meaning as well. If the dissection plane is horizontal, the top line also means top in the floorplan topology, bottom accordingly. If the dissection plane is vertical, the top line means left, the bottom line right. Because of these meanings the tree is called an ordered, oriented dissection tree.

Ework and ebusiness in architecture, engineering and construction

1108

4 THE TRANSFORMATION 4.1 Definitions and basic formulas Before we go any further we have to introduce further definitions. Since we have restricted ourselves to planar floors with constant ceiling heights, we will only consider floor areas a and not volumes. We distinguish two types of floor areas: an net floor area at total floor area Figure 6 defines the floor dimensions in a similar way. We can now derive the basic formulas: (1)

Figure 6. Vertical (1) and horizontal (2) addition of two sibling nodes i and j, parent node k. an=xn.yn at=xt.yt (2) 4.2 Shape functions With the above definitions we define a shape function to be the y-dimension as a function of the x-dimension: yt=at/xt (3)

A model for hierarchical floorplan geometries based on shape functions

yt=an/(xt−xw)−yw or xt=an/(yt−yw)−xw

1109

(4)

Equation 4 shows an interesting behavior. With the typical constraint for rooms that the net floor area an remains constant, the y-dimension is no longer the reciprocal of the xdimension, as Equation 3 would suggest. This behavior results in variations of at as a function of the shape of the total floor rectangle. Therefore, the name shape function is used. In the case of hallways as a realization of circulation areas, the width is a constant. In the case of a hallway in vertical direction, xn=const and because of Equation 1 also xt.yt takes the length of the adjacent space. Thus at can take any value. These two examples show the shape functions we will use in the following procedure. But other shape functions can be defined and used, as long as yt is a monotonous function of xt. Shape functions do not have to be analytically expressed, but can also exist in table form. 4.3 Shape function calculation Shape functions can be easily created for all leaf cells of the dissection tree. Here we will show how shape functions of internal nodes can be derived. Figure 6 shows the two cases of spaces on top of each other (vertical add, horizontal dissection plane) and besides each other (horizontal add, vertical dissection plane). It clearly shows that in the first case, the x-dimensions of both nodes have to match, if unused space has to be avoided. The y-dimensions have to added. xt,k=max (xt, i, xt,j) v-add (5) yt,k=yt,i+yt,j xt,k=xt,i+xt,j h-add (6) yt,k=max(yt, i, yt,j) We use the max-function for the case that the matching dimensions are not exactly equal. In practice this means that the smaller dimension is extended to match the longer one. We also have to observe that the result dimensions only exist in ranges for which valid component dimension values exist. Such ranges are limited by setting reasonable aspect ratio for spaces and especially in the case of the fixed dimension of hallways. In principal, we can express the results in analytical form, using analytical shape functions of the components if they exist. These function are of increasing order as we apply the add-functions recursivly. We also need the inverse functions as we can see in Equation 5 and Equation 6. Therefore, we represent the x and y-dimensions of all nodes as tables of x-y pairs for the range of valid values. As a result of applying the add-functions recursively, according to the orientations of the tree nodes, we finally compute the shape ftmction for the root node.

Ework and ebusiness in architecture, engineering and construction

1110

4.4 Sizing After this bottom-up process of calculating all shape functions, we can now derive the final geometry of a floorplan alternative for a given x- or y-dimension for the root volume. This is a simple table-lookup process with some interpolation if the values are not listed. Let us use the example. The dissection tree in Figure 5 shows a v for the root node (index k). This means that the shape ftinction was calculated using the h-add function. For the floorplan in Figure 4 we chose xt,k=15 m. Therefore, we select the corresponding yt,k value from the root shape function, if it exists. Otherwise, we have to choose a different xt,k value. We now have the outer dimensions of the floorplan volume. In the next step we find the position of the corresponding dissection plane. This can be found by looking up the shape function of one of the children (index i) of the node yt,k, because of yt,i=yt,j=yt,k oientation=v xt,i=xt,j=xt,k orientation=h (7) we find the corresponding xt,i value in the shape function table of node i and have the position of the dissection plane. In the case of a horizontal orientation we exchange x and y. By looking up the wall dimensions we get floorplans as shown in Figure 6.

Figure 7. L-shaped configuration. This process is applied recursively for all children until all leaf nodes are reached. This results in a floor-plan geometry as for example in Figure 4. With a different choice of an x- or y-dimension for the root, we can achieve many different geometries with the same topology. It has to be observed that hallways do not have to be handled differently during shape function calculations and sizing. The information about constant width is captured in the

A model for hierarchical floorplan geometries based on shape functions

1111

shape function of a hallway. Only during the dissection phase we have to guarantee that hallways match in the constant dimension with appropriate volumes so that a solution for a geometry can be found. 4.5 Shape functions for non-rectangular configurations One problem of dissection based floorplans concerns the limitation to rectangular shapes. We briefly outline how shape ftmctions can be applied to certain nonorthogonal shapes. Consider the floorplan in Figure 7, which includes two L-shaped spaces. Each is a superspace, that is, it is decomposed into two rectangular sub-spaces. No wall is assigned on either side of the partition that separates these sub-spaces, that is, the partition can be viewed as a virtual wall with zero thickness. Also note that the internal wall which separates sub-space A.1 and sub-space A.2.1 is completely assigned to the latter. We can define shape functions for the sub-spaces that make up a super-space and compute its total or net regular nodes in our dissection tree, additional nodes area by adding respective sub-space areas. Besides the representing super-spaces are introduced. A super-space node includes references to two or more constituent sub-spaces and holds the super-space area or volume, and possibly, a polygon or polyhedron that is obtained by merging the rectangular sub-space geometries. A shape function for the super-space itself is not required. A floorplan with super-spaces would be redrawn as follows. In a first pass, all nodes of the dissection tree would be visited and evaluated top-down, as described earlier. The shapes of the sub-spaces would be determined according to their shape functions. In a second pass, super-space nodes would be evaluated, that is, area and geometry information would need to be gathered from sub-spaces and processed accordingly. Furthermore, the modification of sub-space area requirements would also trigger the re-computation of the super-space area. 5 TOOL SUPPORT For experimental purposes we have implemented a simple panel and wireframe drawing tool with the necessary data structures for the dissection tree and the calculations for shape function calculations and sizing in the MATLAB toolbox (MATLAB). Most figures in this paper have been produced with this tool. As a further user support we have also created a library of standard floorplan topologies and of standard wall types. Especially for office buildings, typical floorplan types exist can be provided as basic topologies in a library and be refined by further dissection. A typical type is a long rectangular floorplan with one center hallway and two staircase at the ends. Such floorplans can be imported into the tool, further dissected as necessary, and refined by entering net floor areas according to the space program and wall types as far as known. Otherwise, standard wall types as provided by the library can be used in early design stages.

Ework and ebusiness in architecture, engineering and construction

1112

6 DISCUSSION We have shown how floorplan topologies that are the result of dissections, can be automatically translated into valid geometries, including wall dimensions and circulation areas. The approach is based in shape functions that can reflect different geometric constaints. By simple calculations shape functions for all nodes of the dissection tree can be derived. A unique and valid floorplan geometry can be drawn with one additional dimension. The data structures and algorithms have been implemented in the MATLAB environment as a prototype. Experiments have shown that the support provided by the tool for layout planning tasks is straightforward, rapid and that many variations in topologies and parameter settings can be explored in a short time. Interactive floorplan optimizations are the result. We have also shown that simple extensions to non-rectangular shapes can be introduced. Although this is possible with the existing algorithm, further research is necessary to better integrate and support such modification in the design process. Also, nonorthogonal shapes have to be included. One limitation of our approach for orthogonal shapes is that area requirements are presently defined only at the sub-space level. This is because the continuous modification of non-orthogonal shapes is ambiguous. Userdefined geometry constraints could conceivably guide such modifications. Another extension that requires different constraints is the transformation in the zdimension. During the dissection phase, the splitting of a volume into several floors is no problem while creating the topology, even with split levels. The problem arises when wall dimensions and circulation areas are added. The additional constraint that the outer walls of different floors have to match can only be fulfilled by changing the net areas of rooms or by introducing unused area. This problem is also known as stacking and blocking. Other constraints describe the need to place load bearing walls, chimneys or other vertical shafts exactly on top of each other. In principle this can be achieved by iteratively modifying the individual floorplans, but an algorithmic approach should be derived. As a conclusion we have demonstrated the usefulness of a floorplanning approach based on dissection and shape functions and have shown directions of further research. REFERENCES Eastman, C. Automated space planning. Artificial Intelligence 4: 41–64. Flemming, U. 1978. Wall representations of rectangular dissections and their use in automated space allocation. Environment and Planning B: 215–232. Flemming, U. 1986. On the representation and generation of loosely-packed arrangements of rectangles. Environment and Planning B(13): 189–205. Flemming, U. 1989. More on the representation and generation of loosely packed arrangements of rectangles. Environment and Planning B(16): 327–359. Harada, M., Witkin, A., and Baraff, D. 1995. Interactive physically-based manipulation of discrete/continuous models. In Computer Graphics Proceedings, Annual Conference Series 199–208.

A model for hierarchical floorplan geometries based on shape functions

1113

MATLAB, http://www.mathworks.com/ Otten, R. 1983. Efficient floorplan optimization. In Proc. Int. Conference on Computer Aided Design (ICCAD): 499–502. Pfefferkorn, C. 1971. Computer design of equipment layout using the design problem solver. PhD Thesis, Carnegie Mellon University, Pittsburgh, PA. Schürmann, B. and Altmeyer, J. and Zimmermann, G. 1992. Three-Phase Chip Planning—An Improved Top-Down Chip Planning Strategy. In Proc. Int. Conference on Computer Aided Design (ICCAD), Santa Clara, USA. Zimmermann, G. 1988. A New Area Shape Function Estimation Technique for VLSI Layouts. In Proc. 25th Design Automation Conference (DAC), Anaheim, USA: 60–65.

E-learning and education

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Parametric representation of functional building elements with reference to architectural education M.Aygün & İ.Çetiner Department of Architecture, Istanbul Technical University, Istanbul, Turkey ABSTRACT: Conventional formal education methods for construction the introduction of customary functional building elements. Students are presented with the option of either designing or selecting the elements enclosing their spatial arrangement. At this juncture a relational database application is proposed for the purpose of providing support to students in their endeavors to develop satisfactory building elements. The proposed method guides students through the hierarchical levels of element subsystems to achieve coherent functional assemblies.

1 INTRODUCTION Constructive design is an intrinsic part of architectural education augmenting spatial design for obtaining satisfactory overall performance of a building project. Conventional formal education methods for construction the introduction of customary functional building elements, e.g. floors. Various familiar types of these elements are discussed and compared during lectures and tutorials. The implementation of this theoretical knowledge to project work even after supplemented by practical training remains a vague and random process to a considerable extent. Almost invariably students are presented with the option of either designing or selecting the elements enclosing their spatial arrangement. The selection process involves reviewing and maybe modifying the element alternatives which the students have become familiar with during education and practical training. These alternatives are mostly tried-and-tested, thus their performance can be predicted with some accuracy. However in the case of element design a substantial amount of technical knowledge and experience are predicated which are largely notions pertaining to the post-graduate stage. Any stipulation for innovative design sets premature analytical and heuristic demands on graduate students. Hence most of the latter advisedly prefer to adopt or adapt a solution amongst the predetermined set of alternatives. Regardless of which path students are inclined to take, the availability of an educational tool for element development would improve students’ performance as well as their self-confidence in this field which is a cause for much anxiety prior to their professional career. At this juncture a relational database application is proposed for the purpose of providing support to students in their endeavor to develop satisfactory

Ework and ebusiness in architecture, engineering and construction

1116

building elements. The proposed method guides students through the hierarchical levels of element subsystems to achieve coherent functional assemblies. An overview of pertinent publications follows. ISO 12006–2 sets a framework for building classification and hierarchies. Uniclass provides unified classification (Hutchison 2000). Ekholm (1996) applies fundamental semantic and ontological theories to define some basic concepts within classification and to build a conceptual framework for construction works. Mahdavi (1996) describes an object-oriented building representation environment where a class inheritance hierarchy is adopted with which relationships between elements are established. Aygün (2003) also proposes an analytical approach for expressing performance requirements of elements in parametric form in order to provide a basis for comparative evaluation. Aygün & Çetiner (2003) demonstrate the generation of element alternatives by means of a conceptual model. 2 ELEMENT MODEL The proposed ontology for building elements observes the rules of inheritance and encapsulation as the precepts of object-oriented modeling. The orders of hierarchy and inheritance along the entities concerned are accomplished in opposite directions, i.e. hierarchical inheritance. While hierarchy is deductive (top-down), inheritance is inductive (bottom-up). By definition an element must have at least one component which can be connected to another of the same element and also shared by an adjacent element. The branching extends laterally to include all elements in the building system. Hence a physical entity as part of a building is defined as indexed to and also is a function of all its descendant instances, i.e. higher-level entities as embedded objects, in a hierarchical order. The object hierarchy allows any sub-types (descendants) derived from the main types (ancestors) to inherit the accrued attributes while retaining their embedded as well as congenial attributes. Instances of these objects are obtained when actual values are assigned to these attributes as independent design variables of the functional element concept. The synopsis of the element model is presented below: Element Location (External (Below-, Above ground), Internal, Semi-enclosed) Inclination (Horizontal, Vertical, Inclined) Component Type (External finish, Cavity, Protective Layers, Core, Carrier, Supplementary Layer) Geometry (Form, Dimension, Position) Texture and Colour Material Joints (Intra-/Inter-component; Unifying/ separating) 3 APPLICATION Students commence with the element configuration task at the highest, i.e. the most abstract, level of element subsystem in the building system hierarchy. They select at each level the most appropriate value among the alternative values for that element attribute

Parametric representation of functional building elements

1117

offered to them in a context-sensitive form. The alternatives of the subsequent attribute change according to the previous selection. Accordingly students proceed by traversing the element model downwards from the general attributes to the more specific ones. Ultimately the parametric representation of that element is deemed as complete when all the pertinent attributes are specified to which students are directed. The model is transferred to a relational database environment, namely Microsoft Access. The element and component entities are represented as separate data tables with attributes as record fields. The tables are connected by the type of many-to many relationship since an element usually contains more than one component which in turn can be repeated in many elements. In order to validate the model in education, a pilot assignment is carried out for the 4th year students of the Department of Architecture, Istanbul Technical University, asking them to configure the elements of their last building design by means of this model. In comparison to previous 4th year students significant improvements are observed in their ability to define and describe functional elements and components in conjunction with design requirements. 4 CONCLUSIONS The model suggested above enables students to configure coherent functional building elements enclosing architectural spaces by specifying the attributes of the former in a relational database. Hence parametric representation of elements is achieved for students to describe the elements of their building design. Element alternatives can be configured for the purpose of comparative analysis of their performance. Further benefits that may be derived from the implementation of this parametric representation include generation of configurations for plausible alternatives and their appraisal in terms of performance criteria as well as efficient exchange and repository of information for the purposes of performance specification and product development. Thus streamlined retrieval and dissemination of notional and factual information related to buildings and their parts are facilitated acting as a tool initially for students and in turn for all concerned involved in the design or selection process of products related to buildings at various scales. In the prospective phase of this model, other types of elements such as structural and service elements will be included, extending to all other sub- and supersystems eventually enshrining the entire building system. REFERENCES ISO 12006–2:2001. Building construction—Organization of information about construction works—Part 2: Framework for classification of information, International Standards Organization. Aygün, M. 2003. Generation and Evaluation of Building Element Alternatives, Building and Environment, Elsevier Science, Vol.38/5, 707–712. Aygün, M. & Qetiner, L 2003. Conceptual Modeling of Generic Building Elements, E-Activities and Intelligent Support in Design and the Built Environment, Delft University of Technology and Istanbul Technical University, 8–10 October 2003, 85–89.

Ework and ebusiness in architecture, engineering and construction

1118

Ekholm, A. 1996. A Conceptual Framework for Classification of Construction Works, ITcon Vol.1, 25–50, http://www.itcon.org/996/2. Hutchison, A. 2000. BRE Classification Tool: Uniclass, http://cig.bre.co.uk/connet/classifications. Mahdavi, A. 1996. Semper: A New Computational Environment for Simulation-based Building Design Assistance, International Symposium of CIB W67 on Energy and Mass Flow in the Life Cycle of Buildings, 467–72, Vienna.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Life long learning for improved product and process modeling support P.Christiansson Aalborg University, Aalborg, Denmark ABSTRACT: The paper focuses on knowledge transfer and learning based on experiences from developing and carrying through master courses in Industrial IT (MII) and civil engineering at Aalborg University and 25 years of teaching experiences within the field. In the MII the students are recruited from industry to follow a 31/2 years time national open education with most learaing and project work done in an Internet supported distributed environment. The pedagogic method follows a project-based problem oriented learning paradigm (PPBL). The courses cover areas such as; object oriented programming and relational database design, human computer interface and user environment design, computer supported collaborative working, knowledge management, virtual buildings, intelligent buildings, and building systems simulation. Experiences are reported from use of distributed physical and virtual learning spaces, improved learning styles and learning/teaching methods, properties and functionality of digital learning material, improved and adapted pedagogic, tutoring and teacher-student interaction, distributed project collaboration methodology, and industry collaboration. Findings and experiences are illustrated with examples from MII course contents and student project works.

1 INTRODUCTION Information and Communication Technology (ICT) supported learning has come more and more in focus during the last 2–3 decades. The wide spread introduction during 1993 of the World Wide Web (WWW) was a catalyst for deepened interest and extended implementation of learning and knowledge transfer systems. We phase a multitude of challenges in introducing efficient ICT support in the building process from change of working methods, project organisation and improved building product descriptions to increased demand on life-long learning within the fast developing building informatics. The paper focuses on knowledge transfer and learning based on experiences from developing and carrying through master courses in Industrial IT (MII) and civil engineering at Aalborg University and 25 years of teaching experiences within the field. In the MII the students are recruited from industry to follow a 31/2 years time national open education with most learning and project work done in an Internet supported distributed environment. The pedagogic method follows a project-based problem oriented learning paradigm (PPBL). The courses cover areas such as; object oriented

Ework and ebusiness in architecture, engineering and construction

1120

programming and relational database design, human computer interface and user environment design, computer supported collaborative working, knowledge management, virtual buildings, intelligent buildings, and building systems simulation. Courses given within Building Informatics at Aalborg University incorporate results from the teacher’s involvement in ongoing research such as knowledge management and collaboration support using semantic web, IT Support at the Building Site and involvement in the newly started Danish National Digital construction Program (clients’ demands on building modelling and visualisation, project web support and facility management), see also http://it.civil.auc.dk/it/projects/index.html. 2 THE CHANGE PROCESS The learning process has not changed to any considerable degree during the latest centuries. A big shift came when the art of printing was introduced during the middle 1400 (Guthenberg) and it become practical and less expensive to pack and distribute information to a large audience. Today we phase a reality where we (teachers, students) have the freedom to immediately publish, give feed-basck and pack information adapted for different needs and users on the World Wide Web (WWW). We have passed development stages from ‘art of writing’ (2500 b.b.) via ‘art of printing’ (1450 a.c.) to ‘art of communication’ (2000 a.c.) with changed demands on information quality assurance methods, and highly adaptable access media to distributed digital information containers. The most important changes due to introduction of ICT in the learning process are – Higher emphasis on learning (and learning to learn) than teaching. – The teacher becomes more of a tutor (coach, facilitator) than information disseminator. – Greater opportunities for distant learning in virtual environments. – Life long learning becomes an important issue (time and place independent learning). – Globalization with cultural diversity and global market place development with greater possibilities to combine courses from different universities (virtual universities). – Increased modularization of information containers with dynamic formation of higher level containers and inclusion of time marked data. The semantic web provides a first generation tools to relate disperse web based information containers, (Christiansson 2003). – Possibilities to adapt and/or develop new pedagogical methods/learning styles with respect to learning material, learning modes (exploration, discovery, problem based learning etc.), student competence and intelligence profile, improved collaboration, new teacher roles, and social contexts bearing in mind that IT in itself does not improve pedagogy and learning method.

Life long learning for improved product and process modeling support

1121

3 IT IN CONSTRUCTION LEARNING DOMAINS Computer tools were introduced in the education during the mid 1960s. Our IT education experiences are based on course and education systems development as well as teaching from around 1970, – 1972 course in “Computer Controlled Measurements and data manipulation and presentation” at Lund University, Sweden, – 1983 courses in “Cad, and 3D- and database modeling using Medusa”, (Christiansson and Herrera 1985). Workstations were expensive (25.000 US$), – 1986 post graduate course in “Knowledge Based System”, – 1992 “New tools for knowledge transfer—development of hypermedia systems”, – 1995 “To use and evaluate MultiMedia”, and “Make your own MultiMedia Application”. Information and Communication Technology (ICT) is a cross disciplinary domain with strong relations to a number of established sciences such as computer science, cognitive psychology, mathematics, artificial intelligence, social sciences, and informatics. The Construction ICT is by nature also tightly connected to theoretical and practical building sciences.

Figure 1. IT in construction learning domains.

Ework and ebusiness in architecture, engineering and construction

1122

Parts of the learning domains are well supported by learning material e.g. relational database and relation algebra based representations. On the other hand many areas are still under formalization and learning material and courses must be dynamically composed leading to continuous update and development of courses. Figure 1 outlines building informatics related knowledge domains. 4 LEARNING PARADIGM Our possibilities to provide tools that suite different learning styles should be taken into account as we develop ICT supported learning material. The user models are explicitly or more often implicitly hidden in the computer system providing different pedagogical approach and human computer interaction. Learning theories are multitude and research related to many science domains such as psychology, cognition, social sciences, philosophy, and medicine. Here we will focus on some explanations with certain relevance to ICT supported learning, see also (Montgomery 1995), (Gardner 2003), and (Kolb et al. 2004). The learning environment should as far as possible support different learning styles involving concrete experiences, reflective observations, abstract conceptualization, and active experimentation (Kolb et al. 2003) also taking into account that students have different preferences on the way information is accessed. Today you often see reference to four (three) learning styles namely, see also http://www.metamath.com/Isweb/fourls.htm, Visual/Verbal, Visual/Nonverbal, Tactile/Kinesthetic, and Auditory/Verbal.

Life long learning for improved product and process modeling support

1123

Figure 2. The dynamic model of the relationships between practice, research, and education. From (Kjærsdam & Enemark). 4.1 PPBL The PPBL, Project Organized Problem Based Learning, methodology was introduced 1974 at Aalborg University. From (Kjærsdam and Enemark 1994): “The curriculum in engineering as well as in the natural science is project-organized from the day the freshmen arrive until their graduation. The first year the freshmen learn to work in project-groups. The next two years in the undergraduate programs the project work is mainly design-oriented. The last two years in the graduate programs the project work is mainly problem-oriented (Problem Based Learning)…. The duration of each project is one semester. In the program half of the time is distributed to the project work, 25% to courses related to the project and 25% to courses related to the curriculum.” We give two types of courses, SU (study unit) courses covering 25% of available time and PU (project unit) courses covering 25%. The rest of the time is devoted to project work in groups of size 3–5 students. The PU courses are evaluated through the project exams (typically for the assembled group, 1 hour project presentation and an additional 1.5 hours maximum per student) with external censor present. SU courses exams may take several forms as traditional ‘paper based’, and/or oral.

Ework and ebusiness in architecture, engineering and construction

1124

The learning paradigm follows the Aalborg PPBL, Project Organized Problem Based Learning, model. The project is problem oriented and not tied to a specific discipline but requires a cross-disciplinary approach. The projects most often involve industry collaboration and offer opportunity to apply theories in new contexts or to develop new theories. There are not only one-way to solve formulated problems. We normally plan a 4 hours session in the SU courses as, – 2*45 minutes lecture including 10 minutes exercises presentation – Student group work with exercise work – Student group exercise presentation in front of all groups followed by discussion, questions and critique. The students are during the group work forced to articulate and express their ideas and solution propo sals to their colleagues and free to choose presentation format at their wish. 5 LEARNING ENVIRONMENT 5.1 Physical and virtual workspaces In the Master of Industrial IT, MII, education students are situated at different places in Denmark and meet in person at Aalborg University every six week at a weekend seminar for deeper social contacts, personal contact with course tutors, collective questions answering, guest lectures, group works (especially brainstorming and planning), and final examines. New learning IT tools to support self-study, project work, self-assessments, project delivery, communication and course administration are also introduced at those occasions. From (Christiansson 1999) “Distributed learning takes place in a virtual learning space that expands the conventional study chamber and classroom in time and room with regard to learning style and interaction modes as well as learning material and learning methods”. 5.2 Tools and infrastructure The ICT tools broadly falls within the following categories – Human Computer Interaction (HCI) with multimodal access to dynamically composed information containers and applications – Communication and collaboration support (human-human, human-artifact, artifactartifact) – Digital information containers with modularised content and separation between storage and access media. The students have at their convenience, access to course administrated servers for their project programming work, see figure 3. The student project results as well as learning material are stored on (or referenced from) a education web.

Life long learning for improved product and process modeling support

1125

Asynchronous collaboration tools are provided on the education web. Student groups also use tools like Groove, http://www.groove.net/, Yahoo Messenger http://messenger.yahoo.com/, and MSN Messenger (former Netmeeting) http://www.microsoft.com/ messanger, for synchronous collaboration and application sharing. Teacher/tutors are often on student group wishes on stand-by at student email conversation and available for advice.

Figure 3. Students main education access is through the Education Node, EN. If all traffic is channelled through EN it is easier to create administrative data as ‘who-is-on’ and ‘when’, and ‘who has accessed what’. This is though in conflict with direct student access to teacher produced locally stored material. From (Christiansson 2000).

Ework and ebusiness in architecture, engineering and construction

1126

It is important to ensure that learning material is stored under a format that is valid on many computer platforms. For example should PDF or RTF formats be used for documents, web pages be cleared from platform specific non-standard script contents, and standard video sound formats be used. This may not always be possible if specific applications still only are available on some platforms. Students should also be encouraged to avoid fancy non-necessary solutions when reporting or delivering computer based project/exercises solutions. 5.3 Learning material The lecture material is contained in a course web site with all learning material directly available except for books and documents not available in digital formats. Slides and other lecture support material are organized according to figure 4, with a left slide navigation column. The course material is accessed from the education web, EN in figure 3, that also gives access to student project work and administrative courses information.

Figure 4. Lecture material is contained in the course web with graphic/textual navigation frame to left.

Life long learning for improved product and process modeling support

1127

6 COURSE CONTENT 6.1 Master of industrial IT courses Courses given to the Civil engineering students within Building Informatics as well as the Master and Industrial IT (MII) courses, http://www.mii.aau.dk/, covers the domains depicted in figure 1. The Civil engineering courses will not be described here but can be found at http://it.bt.aau.dk/it/education/index. html#civil as well as student projects and student own developed project webs. Three courses are given at the Civil Engineering track (1) IT in the Building Process, (2) Virtual Buildings, and (3) Computer Supported Collaboration and User Environment Design. The MII education spans 31/2 years time (from autumn 2004 compressed to 2 years) and is open for students with a Bachelor Engineering degree and at least 3 years of industry employment. The first year theme is ‘Distributed Information systems’ and is followed by all students in the three specializations, – IT in Construction – IT in Distributed Real-time Systems – IT in Industrial Production – IT in Process control – IT in System Administration. First year courses are – Object Oriented System development, (2 ECTS, PU course) – Human Computer Interaction (1 ECTS, PU) – Databases (2 ECTS, PU) – Fundamental Datanets, Models and Architecture (1 ECTS, SU) – Client/server technology and introduction to Distributed Systems (2 ECTS, PU) – WWW tools (1 ECTS, PU) – Programming (2.5 ECTS, PU) (optional for IT in Construction) – The Virtual workplace (1 ECTS, PU). The second year IT in Construction theme is ‘Models and Communication’ and the special building related courses – Multimedia interface design, usability engineering and Computer Supported Collaborative Work (2 ECTS, PU) – Knowledge Management within Companies and Projects (2 ECTS, SU) – Virtual Buildings 1 (1 ECTS, PU). The third year IT in Construction theme is ‘Integrated ICT in the Building Process’ and the special building related courses – Intelligent Buildings and Digital Cities (2 ECTS, SU) – Virtual Buildings 2 (2 ECTS, PU) – Building Simulations (2 ECTS, PU).

Ework and ebusiness in architecture, engineering and construction

1128

The students will also, according to their personal course portfolio, follow other specialization’s courses during the second and third year for example – Global Information Networks – Company Management – Process engineering – Organisation theory – Distributed systems – Automatic control – Real-time communication systems – Fault tolerant systems – Coding and Security. The IT in Construction specialization gives insight into the role of ICT in the total building process. The participants will gain understanding of and competence in using ICT tools within all phases of the existing and future building process. The participants will be able to formulate requirements and actively participate in analyses, design and development of ICT systems and tools in the construction process as well as practical experiences in use of advanced IT tools. The theme for the 2nd year is ‘Models and Communication’. The aim is to convey theoretical knowledge and deep understanding of some important fundamental domains and ICT-tools that will influence the future development e.g. computer supported collaboration, different types of knowledge representations, analyses and modeling of the building process and building products, and knowledge management. High emphasis is on user needs, requirements formulation and usability engineering i.e. user environment design in relation to the parallel technical system implementation.

Figure 5. Java applet-servlet based web-database connection (student project).

Life long learning for improved product and process modeling support

1129

The theme for the 3rd year is ‘Integrated IT in the Building Process’. The aim is to convey analyses, experiences and examples on advanced present and future use of IT in the different parts of the building process. In this connection the students e.g. work with and analyses building product model exchange using IFC and model checker tools. Also the properties and practical design issues in connection with intelligent buildings and services in the digital cities are investigated. 6.2 Student project examples The student project work always to some degree involves industry collaboration. In many cases the students own company is highly involved in problem and requirements formulations. Examples on students group projects are, see also http://it.bt.aau.dk/it/education/index.html#mii. – “Local history Web”, 2001, involving Java based web-database connection for inquires of historic subjects. (Figure 5) – “Data Warehousing and Knowledge Management”, 2001, involving theory, technology and implementation in business. – “Models and communication to support type house catalogues”, 2002, involving Contextual Design of User environment, information analyses, relational database and user interface design, web 3D models, and database web integration solutions. (Figure 6) – “Use of digital building models”, 2004, involving process analyses and representation, classifications, model access tools, building product model representations, model integration, potential/barriers, and scenarios.

Ework and ebusiness in architecture, engineering and construction

Figure 6. Contextual Design work flow model used for type house catalogue application (student project).

1130

Life long learning for improved product and process modeling support

1131

Figure 7. Digital cities intelligent and responsive building investigation domains (student project). – “Future digital cities and intelligent buildings”, 2003, involving global networks, digital city networks and services, intelligent buildings, ICT solutions, scenarios and the future. (Figure 7) – “ICT tools for building design”, 2004, involving analyses of architectural design tools in use. Requirements formulations on tools, education and design process organization.

7 CONCLUSIONS We are only in the beginning of development of cross-disciplinary university courses in open environments with highly communicative IT tools in contrast to traditional classroom teaching. IT supported distributed learning provides us with excellent possibilities to advance the learning methodologies suitable for life long learning and to render existing courses more effective.

Ework and ebusiness in architecture, engineering and construction

1132

There is a great need to raise the IT competence of the teachers to meet the needs for and carrying through of the changes in education in connection with specification of distributed learning system and tools. ICT tools and learning material knowledge representations and properties must be (at least implicitly) explained to the learners (and teachers/tutors). ICT tools to support collaboration in virtual environments and use of virtual worlds and augmented reality must be further developed in close collaboration with the end users. We will in the future see a closer natural collaboration between universities in course development, and experience exchange. REFERENCES Christiansson P. 2003 Next Generation Knowledge Management Systems for the Construction Industry. In CIB W78 Proceedings Construction IT Bridging the Distance, Auckland, New Zealand, April 23–25, ISBN 0–908689–71–3. CIB Publication 284. (494 pages). (pp. 80–87) http://it.civil.auc.dk/it/reports/w78_new_zealand_2003.pdf Christiansson P. 2000. IT in Distributed Open Learning Environments. In Construction Information Technology 2000—Taking the Construction Industry into the 21st century. G.Gudnason (ed.). Icelandic Building Research Institute. ISBN 9979–9174–3–1. Reykjavik, Iceland in June 26–30, 2000. (pp. 197–208). http://it.civil.auc.dk/it/reports/r_iceland_6_2000.pdf Christiansson P. 1999. Experiences from Design and Use of IT Supported Distributed Learning Environment. In Civil Engineering Learning Technology in Cardiff. R.M.Lloyd & C.J.Moore (eds). Thomas Telford Ltd. London. ISBN: 0–7277–2839–3. (pp. 29–42). http://it.bt.aau.dk/it/reports/r_cardiff_edu_1999.pdf Christiansson P., Herrera A. 1985. Datorstöd i Byggprocessen. Computer Aided Design. (Computer Aids in the Building Process. Cad Systems, Relational Databases, Knowledge Based Systems). Bärande Konstruktioner, und Unioversity. February 1985. (192 pp.). Gardner H. 2003. Intelligence in Seven Steps. in New Horizons for learning. http://www.newhorizons.org/future/Creating_the_Future/crfut_gardner.html Kjæersdam, F., Enemark S. 1994. The Aalborg experiment. Aalborg. Project Innovation in University Education. Aalborg Universitets Press. http://www.auc.dk/fak-tekn/aalborg/engelsk Kolb D., Boyatzis R.E., Mainemelis C. 1999. Experimental Learning Theory: Previous Research and New Directions. Prepared for Perspectives on cognitive learning, and thinking styles. Sternberg R.J. & Zhang L.F. (eds). Case Western Reserve University (40 pp.) http://www.learningfromexperience.convelt_review_paper.pdf/ Montgomery S.M. 1995. Addressing Diverse Learning Styles Through the Use of Multimedia. In The 1995 ASEE/IEEE Frontiers in Education 95 Conference. University of Michigan.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

E-learning with puzzle collages C-J Lin & S-C Chen National Chiao Tung University T-W Chang & L-C Yang National Yunlin University of Science & Technology ABSTRACT: Design learning as a game play. Therefore, such as playful design and design games have become current issues of research in design domain. Game play, especially server-based network game, with the availability of high-bandwidth network environment has evolved to be important social phenomena in the digital era. A framework called design puzzles (Chang 2004) that combines the design as puzzle-making metaphor (Archea 1987) and puzzle games (Bates 2002) provides a match between design exploration and game play. Design puzzle is used in this research as one realization of design exploration. Furthermore, this research investigates the feasibility and computability of a computational model called puzzle-server for describing the design behaviors within the scope of server-based.

1 INTRODUCTION Design learning is similar to playing the games. No matter invoked by playful characteristics (Chang 2002) or the design/game itself (Chien 2002), more and more researches, such as (Klugman and Smilansky 1999, Radford 1997, Woodbury, et al. 2001) are mapping the behavior of playing games as a vehicle to learn design. While most of those researches provide affective inspiration for our research, we adapt the mechanism as well as the metaphor role-play game for design learning design (Chang 2002) as the base of this research. Briefly, by developing an on-line game environment, students can explore potential design proposal and stimulate each other using the mechanism of playing games. 1.1 Design learning as a game play With the availability of broad bandwidth network, Internet not only encourage information exchange but also improve productivity in learning and somehow entertainment. For example, playing games, especially online games on the Internet, becomes more important both in educational and social factors in the modern society. Within networked visual space, online-game players complete assigned missions either alone or by cooperation, sharing with other players in order to win the game. The main characteristic of playing online games is full of interaction, exploration and goaloriented activities.

Ework and ebusiness in architecture, engineering and construction

1134

Four main characteristics of online games are role-playing, process records, information sharing, and hierarchical organizations. How to take advantages of these elements for learning design is the main purpose of this research. 1.2 Exploration design for learning For the interactive learning mechanism with strong game play metaphors, a model called as design space exploration (Woodbury 1991) is used. Design space exploration uses exploration as a metaphor to search design through large number of design alternatives called design spaces. Thus, the design learning is equivalent to design exploring. The consequence of playing a game form different design alternatives in the design spaces. Design space exploration provides the mechanism for an interactive and intrinsic process that is useful for realizing the four characteristics of online game described above. With the ability to explore possible design solutions, the strategies as well as the process is thus an inspiring design learning process. 1.3 Design puzzle Another fundamental concept of this research called design puzzle is based on the similarity relation between puzzle game and design exploration. Further mapping the exploring behaviors of design learning onto puzzle exploration behaviors including puzzle-making and puzzle-solving, design puzzles provide a way to explore the design goals without actual specifying them at the very beginning. This interactive cooperation among participated designers provides insight as well as supporting design decisions during the interactive exploration process. Such cooperation must be related back to the participated designers within the same online game environment. Therefore, with these three backgrounds, this research explores an online game-like environment through the four characteristics of on-line game server: roleplaying, process records, information sharing and hierarchical organizations. 2 ON-LINE GAME SERVER On-line games are not just games but also network services. Online game with clientserver structure can allow a lot of gamers cooperate or compete with each other in a sustainable “world”. This type of game environment is relatively complex and still in its developing stage in the relative short games history. The development of on-line games doesn’t have a clear solution in its own problems. Moreover, the implementation and usage problems created by online games have not been full explored. Most of current available online games are still in the try-and-test stage. In the following, we discuss several common on-line game processes to find out the four characteristics of puzzle server: role-playing, process record, information sharing, and hierarchical organization.

E-learning with puzzle collages

1135

2.1 Connection structure A common network topology used by the on-line game connection structure is client/server oriented. In other words, a game server controls the access of each game, and gamers accessing a game sever act as a client. Therefore, a game server becomes the important control center in the whole on-line game. Therefore, the server for the learning exploration process will be the first step in our research. 2.2 On-line game interactive process Secondly, interaction status of computer games is the interaction between computer and gamers and gamers and gamers in on-line games. There are three interactive behaviors in common on-line games, self-interaction, two-way asynchronous interaction, and two-way synchronous interaction. Since this research is based on mutual communicative learning between learners, self-interaction will not be discussed in this research. 2.3 Internet visual space The greatest character of visual space is that it strides over time and space limit. Computer operation simply becomes the interface for users to enter in this world. On-line games in this visual world follow the rules of game with convenience and ease to exchange and share information among gamers. 2.4 Database management All games processing and missions are saved in a database connected with game servers or called backend in on-line games. Game information constantly transmits to database to have complete game procession and records. 2.5 Role play On-line gamers explore on net and work out game missions. In order to give these movements, role-play is a common practice for implementing the identities and behaviors of on-line games. Gamers with different roles and different abilities can also have different behaviors towards their interaction. 3 ANALYSIS OF PUZZLE SERVER With the description of common process characteristics of on-line games, we then map them onto our corresponded server implementation—puzzle server.

Ework and ebusiness in architecture, engineering and construction

1136

3.1 Role in puzzle server The users on puzzle server are designers. Designers on the puzzle server influent design puzzle exploration process by interactive behaviors. Interactive behaviors in design puzzle include puzzle making and puzzle solving (Chang 2004). As a result of it, puzzle design have different missions in different interactive behaviors. Puzzle making serves to develop puzzle and puzzle solving serves to explore existing puzzles. Therefore, puzzle server need to separate these two user interactions. Consequently, following puzzle making and puzzle solving, puzzle server develops two different roles, puzzle maker and puzzle solver. Puzzle server through role management assigns mission and individually gives mission to develop puzzle and explore puzzle. And then, puzzle server records and shares information through database. 3.2 Process record in puzzle server The exploration process of design puzzle is to search for answers constantly. Therefore, design exploration needs to record the exploration process of design puzzle. Through records, it can display the exploration procedure again and share exploration procedure with others. Design puzzle can then continue to explore information and provide followup design reference on the basis of records. Through records, it can also show the design procedure for the design being re-used. By recording design puzzle exploration process, relevant data of exploration process is collected and then classified. Using design puzzle exploration space records an exploration node in a design space can then record some design puzzle exploration process. Furthermore, process record in puzzle server must record the information situation as clear as possible, and include every state node, connection links and transmission process. Dealing with database can help the realization of process record required. 3.3 Information share inpuzzle server Information sharing in puzzle server can let users share exploration information and experiences of others, and stimulate each other as a learning strategy. From the part of design puzzle exploration; a visual space also can be through similar sharing machinery. It can let designers work out their own design puzzle creation and exploration in the visual net world and share the design exploration process with other designers to help them integrate relevant knowledge. In speaking of design puzzle, it is the direct help and stimulation. Puzzle server used asynchronous mode, so the interactive sharing contents have to be shared by information recording. By recording process information into database, Puzzle server can then provide information sharing for other users.

E-learning with puzzle collages

1137

3.4 Organization in puzzle server The exploration process contains information of design puzzles that is complex and has no common organization rules. A hierarchical organization is needed for users to be understood and control. Puzzle server uses database to do information record and sharing. As a result of it, puzzle server not only provides computational information organization but also combines database organization. After dealing with design puzzle information, puzzle server displays different and helpful feedbacks back to users for further exploration. This interactive way can record data through data conversion and organization and display in different style just like sharing information. Operation method in this trend is to record database saving and withdraw and data organization before sharing. 4 PUZZLE SERVER MODEL After understanding both the requirements of puzzle server and the characteristics of online game server, we then develop a system for realizing these concepts. Through the contrast between design puzzle and exploration behavior, four layers according to the four characteristics of online game server are developed as the system layers of puzzle server. First layer is user information, second one is puzzle representation, third one is puzzle transition and fourth one is exploration process. The model is based on these four layers to construct design puzzle interactive behaviors. Every layer covers different information transmission, data management or mathematical calculation and different visualization result. Each layer is described as following sessions. 4.1 Four layers of puzzle server 4.1.1 Layer 1: user information User information layer serves mainly for users to deal with information on puzzle server. Design puzzle users give users roles, puzzle maker or puzzle solver and behaviors, puzzle making or puzzle solving. And then it connects with puzzle representation layer to display the relation between roles and puzzles. The operation transition is shown in Figure 2.

Ework and ebusiness in architecture, engineering and construction

Figure 1. Puzzle server model operation.

Figure 2. User information layer operation situation.

Figure 3. Puzzle representation layer operation situation.

1138

E-learning with puzzle collages

1139

Figure 4. Puzzle transition layer operation situation. 4.1.2 Layer 2: puzzle representation Puzzle representation layer mainly serves to display puzzle in puzzle server. Producing puzzle includes puzzle information developed by puzzle maker and puzzle hint converted from design concepts to knowledge structure meaning by symbols and puzzle rule. These three elements converted by puzzle transition layer display puzzle (shown in Figure 3). 4.1.3 Layer 3: puzzle transition Puzzle transition layer mainly serves to transit puzzle in puzzle server. According to existing facts of puzzle and puzzle rule made by inference engine (Yang 2004), puzzle is converted as the result of puzzle transition. Puzzle transition will then be recorded by exploration process layer and displayed by puzzle representation (Figure 4). 4.1.4 Layer 4: exploration process Exploration process layer mainly serves to record and display puzzle in the process of exploration of puzzle server. After puzzle transition layer, puzzle produces new puzzle. This procedure is recorded by exploration process layer and then organizes new structure. This organization will then be displayed by user information (shown in Figure 5). 5 PUZZLE SERVER SYSTEM With four layers and their transition relation described above, we then describe the implementation based on one realization—puzzle collage.

Ework and ebusiness in architecture, engineering and construction

1140

Figure 5. Puzzle transmission layer operation situation. 5.1 Design consideration For the implementation consideration, one type of design puzzle called puzzle collage is applied as the domain problem. Puzzle collage combined by several small pictures of certain meanings or relation produces a piece of collaged picture according to different combination. While pictures display different meaning, is regarded as different information from original pictures. Pictures can stimulate designers to have ideas in their learning exploration stage. Therefore, designers use pictures to search design inspiration in learning design. Such behavior is similar as operating puzzle gathering and pasting to search a certain picture. Consequently, this system uses and operates puzzle gathering and pasting as the example of this research. From server point of views, the stability and efficiency is important consideration in system environment and technology consideration. Linux operating system is used according to its stabilities, development support, and efficiency. Therefore, whole environment of puzzle server sets up mainly in Linux. It is good to deal with active homepage, especially it has a complete function of PHP language in editing pictures. MySQL system is used as system database, which serves to look up language. The interface based on interactive operating software design provides many helpful tools. Furthermore, through ActionScript wording control, we use Flash for its interactivity. 5.2 The system According to consideration mentioned above, this system is Sset under Linux and takes 2D puzzle collage as an example for realizing the system model of puzzle server. The system is based on an on-going research project called Design Puzzle Collage System (DUCS). DUCS development (shown in Figure 6) is constructed on the website and using web as display space for the puzzle server. Users can use it to explore existed ideas proposed by themselves or others. All users can set it up on the basis of net saving and withdrawing process.

E-learning with puzzle collages

1141

Figure 6. DUCS system organization. There are four modules of the system—user module, puzzle creation module, puzzle operation and puzzle sharing. User module is the first layer of puzzle server model. This module uses passwordverifying machinery to give users rules and constraints. Puzzle creation module is mainly to establish puzzle and realizing puzzle representation. Its main function serves to develop puzzle. Users can key in basic concepts of puzzle design through system interface and transmit design sketches. The information will be recorded in the system, puzzle database and produce puzzle hint by setting keywords through design sketches. The main operation principle is puzzle information and puzzle hint resources based on the second layer of puzzle server model, puzzle representation. The main function of Puzzle operator module serves to puzzle operating part, which belongs to the second and third layer, puzzle representation and puzzle transition. Through puzzle choice and design participating, design exploration can then be divided into puzzle making and puzzle solving. Puzzle sharing module mainly serves to display puzzle exploration structure and according to the four layer of puzzle server—exploration process. The main function is that users can choose and participate puzzle and display organization and branch of whole puzzle by tree diagram. Users can select puzzle and insert it into design branch. Users can then design or start another puzzle design process. 5.3 Operation result evaluation After operating DUCS system, puzzle server clearly display whole design puzzle exploration procedure in the system. While using design sketches as design concepts, symbolic meaning of design concepts is labeled by keywords (shown in Figure 7) and its topological structure is framed as the basic knowledge structure to produce puzzle alternatives. Under this organization, the conversion and transition of design alternative (the design puzzle/collage) is displayed as the consequence of exploration outcome. Design exploration constantly develops and grows up; as a result of it, the whole exploration

Ework and ebusiness in architecture, engineering and construction

1142

Figure 7. Transition of design concepts. process actively becomes a dynamic graph diagram (in our case, we only implement the outcome as a tree diagram as a simplified version). Through this diagram, the (self or group shared) learning outcomes can be visual displayed as the consequence. Therefore, the design exploration from server can then be clearly explained. 6 CONCLUSION Computers make design be recorded and the Internet makes design be shared. Every stage of design is the display by designers at that particular moment. Maybe one stage is unused, but the idea at that moment can be a different thinking stimulation to other people or other designs. Many great designs were often picked back from trashcan with this learning situation. Furthermore, every procedure of design shall not be throwing away. Instead, proposing this puzzle server organization can let design process complete and make design knowledge be displayed again and reused to shorten the process of design learning invention. Based on puzzle server concepts, it serves as design record and design procedure sharing and provides a new potential way for future design learning mode. REFERENCES Archea, J: 1987, “Puzzle-Making: What Architects Do When No One is Looking.” in YE Kalay, (ed.), Computability of Design, Wiley-Interscience, New York, pp: 37–52. Bates, B: 2002, Game Design: The Art and Business of Creating Games, Premier Press. Chang, T-W: 2002, Pedagogy or Andragogy: a role-interplaying approach for digital media learning., in M Luther (ed.), ANZAScA (Australian and New Zealand Architectural Science Association), School of Architecture and Building, Deakin University, Geelong (Australia), pp: 69–76. Chang, T-W: 2004, Supporting Design Learning with Design Puzzles—Some Observations of Online Learning with Design Puzzles, in, 7th International Conference on Design & Decision Support Systems in Architecture and Urban Planning, DDSS, Northland, pp: (to be published). Chien, S-F: 2002, Design Gaming, Designing Games—Learning Design through Game Playing and Game Making, in, Proceedings of 20th eCAADe Conference, eCAADe, Warsaw (Poland), pp: 28–33. Klugman, E and Smilansky, S: 1990, Children’s Play and Learning: Perspectives and Policy Implications (Early Childhood Education Series), Teachers College Press.

E-learning with puzzle collages

1143

Radford, A: 1997, Games and Learning about Form in Architecture, in, Challenges of the Future, 15th eCAADe Conference Proceedings, eCAADe, Vienna (Austria), pp. Woodbury, RF: 1991, Searching for Designs: Paradigm and Practice, Building and Environment, 26(Pergamon Press): 61–73. Woodbury, RF, et al.: 2001, Games in Early Design Education. Playing with Metaphor, in, Proceedings of the Ninth International Conference on ComputerAided Architectural Design Futures, Kluwer Academic Publishers, Eindhoven, pp: 201–214. Yang, L-C, et al.: 2004, Exploring Visual Information with Puzzle Rule—A Design Collage Approach, in, ISARC 2004, International Symposium on Automation and Robotics in Construction, Jeju island, Korea, pp: to be published.

eWork and eBusiness in Architecture, Engineering and Construction—Dikbaş & Scherer (eds.) © 2004 Taylor & Francis Group, London, ISBN 04 1535 938 4

Author Index

Adam O. 475 Ahmed V 29 Akin Ö. 205, 529 Akinci B. 205 Amor R.W. 35 Antoniadis G. 409 Anumba C.J. 273,377, 491, 547 Aouad G. 29, 415 Arayici Y. 29, 415 Augenbroe G. 273, 377 Aygün M. 665 Babič N. Č. 515 Badinelli R. 281 Balaton E. 179 Balder R. 179 Barakat T.A.H. 215 Barrère G. 371 Barresi S. 319 Bazjanac V. 41 Beer D.G. 49 Bektas F. 603 Benjaoran V. 223 Berkhahn V. 257 Beucke K. 49, 149 Bi G. 629 Bignon J.C. 563 Blokpoel S. 423 Bocquet J.C. 155 Boer S. 649 Bouchlaghem N. 547 Bowden S.L. 491 Brandon P.S. 11 Bravo-Aranda G. 171 Bungartz H.J. 141 Çagdaş G. 635, 641

Author index Cai Q.Y. 305 Carlsen M. 311 Carrillo P.M. 547 Carter C.D. 385 Casals M. 437 Cassel-Engqvist E. 231 Castro S. 237 Çetiner İ 665 Chang T-W. 675 Chen S-C. 675 Christiansson P. 667 Crawford J. 431 Dainty A.R.J. 215 Dawood N. 223, 237, 263 de Wit E. 355 Deshayes P. 155 Díaz J. 483 Dikbaş A. 245, 297, 595 Dolenc M. 161, 179 Dorr A. 491 Drogemuller R. 431 Duhovnik J. 161 Durusoy S. 245 Ediz Ö. 635 Edwards D.J. 215 Egan S. 431 Eir A. 59 Eisenblätter K. 505 Ekholm A. 67 El-Diraby T.E. 337 Emborg M. 109 Farinha F. 91, 171 Feltz F. 371 Ferreira da Silva C. 319 Fiès B. 319 Firmenich B. 49, 77 Fischer M. 117 Flanagan R. 3 Forcada N. 437 Froese T.M. 19, 85 García I. 569 Garrett Jr J.H. 205 Gehre A. 445 Goksel C. 603 Goldfarb I. 453 Greb S. 291

1145

Author index Grilo A. 349 Gursel I. 205 Halin G. 563 Hamilton A. 29 Hammer C. 475 Hannus M. 179 Hassan T.M. 273, 377, 385 Häusler S. 363 Hernández-Rodríguez F. 171 Hofer A. 475 Holtzhauer E. 97 Hopkinson L.L. 609 Huhn M. 461 Icoglu O. 103 Jardim-Gonçalves R. 91, 349 Jerrentrup M. 475 Jessurun A.J. 355 Jongeling R.P.M. 109, 423 Jung Y. 577 Kamara J.M. 547 Katranuschkov P. 179, 187, 249, 445 Kaya S. 603 Keller M. 249, 505 Kernstock S. 363 Kisacikoglu B. 641 Kiviniemi A. 117 Klinger A. 257 Kondratova I.L. 453, 499 König M. 257 Kubicki S. 563 Lai Y-C. 311 Leinenbach S. 475 Lima C. 319 Lin C-H. 675 Magdič A. 515 Mahdavi A. 103, 127, 363 Mallasi Z. 263 Maló P 349 Mangini M. 273 Marasini R. 223 Martinez M. 135, 569 Medjdoub B. 629 Meissner U.F. 291 Menzel K. 249, 409, 505

1146

Author index Metzger A. 195 Mills T. 577 Molina J.M. 135, 569 Mundani R.-P. 141 Naaranoja M. 371 Nabrzyski J. 179 Ng F.F. 305 Niggl A. 141 Nour M. 149 Olofsson T. 109, 231, 423, 587 Oosterhuis K. 649 Otjacques B. 371 Oumeziane H. 155 Özkaya I. 529 Pazlar T. 161 Pellegrini R. 615 Perdomo J. 281 Praper P. 583 Radev D. 621 Radeva S. 621 Rank E. 141 Rebolj D. 515 Rees R.V 329 Ren Z. 273, 377 Richter T. 49 Roca X. 437 Romberg R. 141 Rueppel U 291 Ryoo B-Y. 393 Saal H. 97 Salmelin B. 25 Salvaneschi P. 615 Sanal A. 467 Santos I.A. 171 Saroglu E. 603 Schapke S.-E. 539 Scherer R.J. 187, 445, 539, 621 Sey Y. 595 Shelbourn M.A. 385 Skibniewski M.J. 393 Snow C. 609 Stehn L. 231 Steiger-Garcao A. 91 Steinmann R. 521 Suter G. 363, 657

1147

Author index

Tan H. 547 Tanaçan L. 245, 297 Taş E. 245, 297 Tatari M.O. 393 Thabet W. 281, 577 Thorpe A. 491 Tolman F. 329 Toprakli A.Y. 595 Tseng M.M. 553 Tullberg O. 587 Turk Ž. 179, 399 Turkaslan-Bulbul M.T. 205 Udeaja C.E. 547 van Leeuwen J.P. 355 Vegchel W.V 329 Wallmark T. 553 Wang H. 205 Weise M. 187 Woksepp S. 587 Yaman H. 245, 297 Yang L-C. 675 Zang S. 475 Zimmermann G. 195

1148