0 1con.Ncl Ply I-ld 2006

]Tor f u r h x i i i lb rmi i~ io i i 011 uiir publications, p h s e visit our website: www.coiishuct ioii-innovnlioii.inTo

Nalional Library ol'Ai1stri11 in. Celnloguitig-iii-Publicatioii data

Clients driving construction innovat ion: mapping the tcrrain.

Bibliography.

1. Conslructiun iiitlustry - Tcchno log ica l innovations. 2. Construction industry - Technological innovations - Austmlin, 3. Civil ongincering - Technological innovations. 4. Civil engineering - Technological innovations - Australia. 1. Brown, Kcrry. IT. I-Imipsoii, Keith D. (Keith Douglas). 111. Brandon, Peter S. IV. Cooperative Rcscarch Centre Tor Construction Tiinovalion (Australia).

338.768

ISBN 1-741071 2-8-3

ii

Contents CONTRIBUTORS vi i

FOREWORD xvii

CIB TASK FORCE 58: CLIENTS AND CONSTRUCTION INNOVATION xviii

ACKNOWLEDGEMENTS xix

PART I CLIENTS DRIVING CONSTRUCTION INNOVATION

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

Chapter 7

Chapter 8

Chapter 9

Moving Ideas into Practice Kerry Brown and Keith Hampson 2

Should Clients Drive Innovation? Mind, Method and Motivation Peter Brandon 5

Adopting Innovation: Building Information Models in the Finnish Real Estate and Construction Cluster Arto Kiviniemi 15

PART 2 MEETING CLIENTS’ NEEDS

Industrialising Residential Construction for Small to Medium Size US Home Buiders Thomas Mills, Ron Wakefield, Michael O’Brien

Ensuring Value for Money: A Value Management Approach to Manage Multiple Stakeholders in the Briefing Process Geoffrey Shen

The Client’s Role in Driving an Appropriate Project Culture Leading to Innovative Performance Outcomes Jian Zuo, David Ness and George Zillante

PART 3 PROCUREMENT AND RISK MANAGEMENT

Rebalancing Risk and Rewards Jim Doyle

Client Capabilities and Capital Works Procurement Policies: A Comparative Analysis of Australian Jurisdictions Craig Furneaux, Kerry Brown, Don Allan, Neil Abel, Sheena McConville, Stephen McFallan, Kerry London and John Burgess

Cost of Tendering: Adding Cost without Value? John Dalrymple, Lionel Boxer and Warren Staples

25

32

43

55

62

72

iii

Chapter I O

Chapter I 1

Chapter 12

PART 4

Chapter 13

Chapter 14

Chapter 15

Chapter 16

Chapter 17

Chapter q8

Chapter 19

Chapter 20

Clients’ Building Product Eco-Profiling Needs Delwyn Jones, Phillipa Watson, Peter Scuderi and Pene Mitchell 80

Difficulties in Defining Product Sustainability Shane West 90

Effecting Sustained Innovation in the Construction Procurement Process Martha Murphy, George Heaney and Srinath Perera 99

INFORMATION AND COMMUNICATION TECHNOLOGIES IMPROVING EFFICIENCIES

Early Automating Code Checking For Building Designs - Designcheck Lan Ding, Robin Drogemuller, Mike Rosenman, David Marchant and John Gero 113

Early-Design Stage Parametric Building Development John Crawford, Robin Drogemuller and Gerard0 Trinidad 127

Comparing Distance Collaborative Designing Using Digital Ink Sketching and 3D Models in Virtual Environments Mary Lou Maher, Zafer Bilda, Figen Gull Yinghsiu Huang and David Marchant 133

Towards a ’‘Loosely Wired” Design Optimisation Tool Wei Peng and John Gero 143

Ontology-Based Demand Support Systems for Urban D eve1 o pm e n t Hans Schevers, Dajon Veldman, Fanny Boulaire and Robin D rog em ulle r 149

Wayfinding Swarm Creatures Exploring the 3D Dynamic Virtual Worlds Ji So0 Yoon and Mary Lou Maher 156

PART 5 PERFORMANCE BASED BUILDING

Performance Based Building R&D Roadmap Towards Europe’s Vision 2030 for Construction Greg Foliente 163

Performance Based Procurement Practices Selwyn Tucker 175

iv

Chapter 21

Chapter 22

Chapter 23

Chapter 24

Chapter 25

Chapter 26

Chapter 27

Chapter 28

Chapter 29

Chapter 30

Chapter 31

Performance Based Building Design Process - PeBBu Domain Agenda and Future Development Needs Lam Pham, Peter Boxhall and Dik Spekkink

Project Diagnostics - A Cure for Poorly Performing Construction Projects Daniyal Mian and Adrian Morey

PART 6 CONSTRUCTION HEALTH AND SAFETY

Using Safety Culture t o Overcome Market Force Influence on Construction Site Safety Herbert Biggs, Vaughn Sheahan, Donald Dingsdag and Dean Cipolla

Safety Culture in the Construction Industry: Changing Behaviour through Enforcement and Education? Donald Dingsdag, Herbert Biggs and Vaughn Sheahan

Managing Employees’ Work-Life Balance: The Impact of Management on Individual Well-Being and Productivity Lisa Bradley, Caroline Bailey, Helen Lingard and Kerry Brown

Supporting the Design OHS Process: A Knowledge-Based System for Risk Management Helen Lingard, Andrew Stranieri and Nick Blismas

Developing a Code of Practice for Construction OHS: A Research Agenda Janet Pillay, Michael Charles, Rachel Ryan and Tim Fleming

PART 7 FACILITIES MANAGEMENT

Facilities Management in Italy: Between Traditional and Innovative Approaches Lorenzo Bellicini and Alessia Salaris

FM Service Quality Indicators - Benefiting Supplier and Customer Hermen Jan van Ree and Peter McLennan

Facilities Management as the Catalyst to Accelerate the Evolutionary Changes in Workplace Architecture Agustin Chevez, Guillermo Aranda-Mena and Peter Edwards

PART 8 INDUSTRY DEVELOPMENT

Collaboration and Engagement Throughout the Supply Chain: The Role of Government Neal Ryan, Michael Charles and Keith Hampson

V

182

191

201

21 4

220

225

235

247

25 1

260

267

Chapter 32 Public Policies and Innovation in the Construction Industry Kristian Widen 275

Chapter 33 Measuring the Technical Competence of Repeat Public-Sector Construction Clients Karen Manley and Stephen McFallan

Chapter 34 Understanding the Innovation Adoption Process of Construction Clients Andreas Hartmann, Geert Dewulf and Isabelle Reymen

281

288

Chapter 35 Cross-National Research on Barriers to Construction Automation and Robotics Implementation in Australia and Japan Rohana Mahbub and Matthew Humphreys 295

Chapter 36 Facil itating Technology Transfer in the Construction Industry David Thorpe and Neal Ryan 303

Chapter 37 A Reflexive Capability Model for Sustainable E-Business Environments in Construction Supply Chain Kerry London and Nathaniel Bavinton 31 3

PART 9 SUSTAINABLE CONSTRUCTION FORTHE FUTURE

Chapter 38

Chapter 39

Chapter 40

INDEX

Leaving Today’s Future of Building Behind Mart in Fischer

Fibre Composite Innovations in Australia’s Construction Industry Gerard van Erp, Craig Cattell and Da Huang

PART 10 MOVING IDEAS INTO PRACTICE

Key Lessons and Conclusions Keith Hampson, Kerry Brown and Peter Brandon

338

341

350

354

vi

CHAPTER 17

Ontology-Based Demand Support Systems for Urban Development

Hans Schevers Dajon Veldman Fanny Boulaire

Robin Drogemuller

INTRODU CTlON Urban dcvclopment projects often have a prominent appearance and can h a v ~ a great impact on the environment. The total iiiipact and the value appreciation can involvc many staltcholders, iiicluding the client. Unlike several other industries, malting ii prototype in thc building and construction iiitlustry is norinally iiol feasible. Clieiits and slakcholdcrs i n urban devclopnicnl projccts cnniiol inspect the physical end rcs~ilt M o r e lliey “buy” it. Obviously this is significantly differcnt froni buying a product in a shop, which yon can see, feel and even bring back when YOU liave changed your iniiid. The clicnt is nevertliclcss involved in tlic tlyiiainic process in which nn inban developmeiit evolves Doli1 idea to final product. Mosl clients tire not ktinilitir with this proccss and therelbre inay not be awarc of tlic risks they run. Changing ideas in later phases, likc changing ideas in the construction phase, can be vcry costly, In other words, the initial decisions inay have a large impact on the project. It is therefore important that the client and other stakeholders ~orinulatell‘ormalise their requircinenls correclly. Learning inore about the design issues and characteristics by inspccting dirfercnt dcsign solutions, for example, cnn incrcase the client’s insight (Zeisel 198 1). This increased insight inay cause changes in tlic requirements. Deiiiand suppoit sysleliis (DSSs) can help clients by presenting design solutions using virtual reali ty, and by offcring rclcvant feedback such as costs, energy usage, clislances and density (Sclicvers 2004).

DEMAND SUPPORT SYSTEMS The goal of a DSS is to supporl clients with access to the body of constrticlion knowledge (Schevers 2004). With this acccss, clients can increase their insight tilid become wcll informed. Using a DSS, clients can experiment with llieir requirements and see the co~iseqt~c~~ces . Basically, ihcy a re nblc to ni i i “what-if” sccnarios to increase their miderstanding of their own requirements (what is valuable to the client), and enable tlicin to explore the design space (explore what is possible). These kinds of virlual prototyping capabilities are perceived as important drivers for construction innovation (CRC CI 2005).

Nowadays, many different models are available that deal with land usc, transportation, sustainability, costs, energy usage (demand and supply), urban water (danwid and supply), noise, airflows, sbading, Atistralhn Model Code for Residential Development (AMCORD 1992), accessibility (public transport), (lire) safety, aesthetics, construclion planning etc. Intcgrating DSSs with thcse kinds of models would support clieiits even further. Clients could experiment with dirferent design solutions and get I~iLiIti-discipliiia~ fcedback using llie existing models.

Developing demand support systems Obviously, developing a DSS that can handle all diffcrent situations arid predict all aspects of an urban developineiit project will take an enonnous cffort, and arguably such a project would havc to tackle several (technical) problems. Ifowever, with (lie increase in the reusability ol‘ software compoiienls, building a specific software application dedicatcd to one project becomes more feasible. This iiieaiis that the modelling approach is directly related to the urban dcvelopmeiit projecl, and uses the inforinntion and knowledge that is at hand within that project. Building a software tool for a specific project is, of course, easier than a generic oiic that needs to be tiseful €or all projects. Ilowever, building such an applicalioii from scratch caii be costly and tiiiie consuming. Therefore, a modclling eavironmenl is necessary where project-specific models can be developed while reusing generic components. Such an environment enables the creation of a custom-made DSS by dcveloping project-specific parts using a iiiodelling environment, and by also reusing existing coniponciits that are applicable to a specific project. Bnsically, it is like having a library of components and models that can be changed and reused. New project-specific DSSs wodd be composed of these already available components by reusing bits and pieccs of other urban development models that also apply to tlie project.

149

Ontology-driven software To eiiitblc soltware components to bc reused, interopcrability is necessary betwccu the coqionents, which nowadays can be achieved by ontologies. A definition of ai ontology is a conceptualisatioii Of things in a computer- interpretable fonnat (Klein 2002). By relating inacliinc-inlcrpletable inforination lo each olhcr, inference suppor~ can help consistency and can support Curther interoperability (Gruber 1995). For example, consider tlmt n, b anti c are information pieces that are necessary for different applications to rtin. Whcn cr = b and 0 = C, then you cool~l infer that n = c. This mcaiis that a piece of inforlnation can also bc used for anothcr application. Olitologies try to describe informatioii in such a way that these kinds of infcrcnccs can be made. An open-source tool that can dcvclop these ontologies is Stanford Medical laformatics (2000) ProtCgC tool. Using Protkgk, classes, propertics niitl relalionships between the classes can be constructed using grapliical user intcrl‘aces (Figure 17. I). For instanccs of these classes, a form is coiistnicted automatically, which enables values to be se1 I‘or each Iiropcrty, or relationships, to be set between instances (Knublauch 2003). As the ontology is machine-iiiter~~rctab~e and standardised, mnny other applicatioiis can read from this ontology. For exiunple, the oiltology can be extended with behaviour by knowledge representation languages and inference engines (Sown 2000). The infercncc cngines enable rules to bc executed on the ontology. As the rule, eilgines have differetit characteristics but all use the smnc olitology, and SO 11 rich set of features is available for developers. Different ontologies with different rules can bc crealed iiiid exchaiiged with each other. Due to the machine interpretability, consistency checlts call Lie pcrrormed automalically or new class hierarchies can be determined, and so forth.

Decision table plug-in Using the ProttgC’s software, a decision table plug-in has bcen developed that opcratcs tlircclly 011 the onlology. Decision tables can be defined for each class in the oIitology defined in ProtkgC. A decision table accominodatcs lllc development of simple “if ... then” nilcs in a tabular forinat (Figure 17.2). Each decision table has a conditional p a i i and an action part. In the condition part, the conditions are forinulated. When an instancc of the class meels thcsc conditions, the actions specified in the same column of tlie decision table will be carricd out. Figure1 7.2 shows IIIC following example: if the height is 30 or lower than tlie type, the property is set to “low-rise”.

Rule-based system A graphical nile editor has been made to facilitate the creation ofrules. It allows the crcation of thc conditioii parl or an “if <condition> .. . then <action>” rule. The differeiice with the decisioii tdlc is tlut the conditional part \llr\y contain several interrelated classes. The nile engine will search for instances that comply with the specified pattcrll. Properties are connected to a script using input and output relations (Figure 17.3). The script contailis code thal may contain fonnulas using the input properties to calculate tlie output properties. Furthcrniore, the script also allows links to other programs such as spreadsheets. In this example, tlie script can insert the input valucs into a spreatlshcel and retrieve the output values.

150

Figure 17.1 : Screenshot of the Protege Ontology Development Environment

Figure 17.2: Decision Table Plug-in

151

Figure 17.3: Screenshot of the Rule Editor

Base system

1 ,

Classes defiiied in the ontology caii bc relatcd to each other to form a conditional pattern. The rule engine will search ibr the pattern and execute tlie script,

Library

Building a demand support system Several ontologies, rules aiid applicalioiis have been created that can be tiscrtil in most urban development projects, such as a geometry ontology and a 2D viewer. The 2D viewer is able to visualise tlie geometries that arc stored in classes, such as polygons and polylines. Tliese classes can bc extcnded casily. For example, a liousc or strect class cat1 be extcnded from a polygon class. This ineaiis llial the 2Dviewer can be used to visualisc liouscs and streets. In addition, tlie dccision table plug-in, the graphical rule editor and tlie otlicr rulc languages can all be tised at the same time, This inenns tliat rules and decision tables can be developed using tlie classes in tlie ontology. Figure 17.4 shows the conceptual architecture of the deniaiitl support prototype. The library contains ontologies, tlccisioii tables, niles a i d applications that can be reused casily. New classes can be ciefiiied using thc ontology cdilor aiid caii be related to tlie existing (library) ontologies. The behaviour of these new classes can be tlcfined using decision tables aiid rule-based systems.

Figure 17.4: Conceptual Architecture for Ontology-Driven Client Support

The first step in developing a customised DSS is to define an appropriate ontology. This mcaiis that all the classes and their relationships relevant to the project need to be defined. Tliese new classes can be related to existing classes and can even inherit their behaviour, For example, defining a house class by extending a polygon class means that the object house can be visualised using tlie 2D viewer. The second step is to define the ticcessary behaviour by developing, for example, decision tables, mles and scripts. New properties such as house type and costs can be attached to the house class. Via a decision table, tlie house type property can be related to, for example, the cost by inserting simple cost fonnulas. This approach enables the DSS to be customised very quickly. Obviously, tlie newly defined objects (decision tables, niles, scripts etc.) and their behaviour can become available to other projects, supplementing the library.

152

Demand support systems for urban development TWO differcnt DSSs have been devcloped by creating an oiilology and dcfining behaviours using rulcs and decision tables. The first DSS deals with master plans. The second DSS deals with neiglibourliood designs.

Case I : Master plan

The ont0iog)I The oiltology of a inasler plan DSS cOnlr?inS the classes, SLlCh as precinct, that can be decomposed into zones that coiipain zone fuiictioiis such as infrastructure. residential or park. Each fiinction has a property tlefiiiing the pcrceiitage or the zone that is used for that runclion. The idea is that the uscr can select a zone a1id insert which flinction it iiecds to have. Further spccifications of each ftiiictioii have been macle: for example, the residciitial function has a property house type, which hils valt~es (large detached dwelling, semi-dctached dwelling, townhouse ctc.).

The bchavioiiis The bchaviours are of c o m e based 011 the 01ilology. The decisioii table plug-in is used to set nuniber values for the filiictioiis based on choices. For example, whcil the user changes the house type iu a resideiitial function from a large dctachcci dwelling to a townhouse, the dccision table will react and change the valuc for the avcrage lot size for a house, thc average watcr demand, tlic cost etc. Rules are created that calculate how inany of these houses can be built in the zone. Siiiiilarly, rdcs have been devclopcd for the othcr fiiiictions (inkastructure Rinctioii, park ctc.). In nc\tjition, the nile-based systeiii is used to aggrcgate values of all zoiies, giving a suiiimary of the total precinct.

The rilcisler ~ / C I I I DSS using polygoii information from a CAD or GIS file, zoiies can he defincd. Each zone contains fuiictioiis that have scvcrfil properties that cui be chaiigcd by the user. Bach changc will have nn effect on the zonc and, after tliai, 011 the precinct that is coiiiprised of tlic miles. Tlic value OT Llic properties of the precinct is displayed iii charts. So wlicn tlie user inakcs a change somcwhcre in a zone 01. hi a zoiic runction, the charts are updated automatically (Figure 17.5).

Case 2: Neighbourhood level

The o/?/o/ugl’ Thc neighbourhood DSS deals willi n r l x ~ ~ ~ dcvclo~mienl on a more dctailcd level compared with the mastcr plan DSS. A precinct (reuscd h i i i thc master 1)hi oiitohgy) contains clcmcnts such as regions, strecls, parks, wnlcr, sliopping malls, commercial rcgions and pub1 ic lriinsporl buildings. h i elcincnt is a subtype of shape, and coiisequcntly can hold gcoiiiclry. Rcgions have n?any propertics such as house Lype, and reuse the decision tables fiom the prcvious exaiiiplc containing knowlcdgc relating to house typc with lot size. Other properties arc rent prices, water demand, amounl of parking spaces, dislaiiccs betwceii public transport aiid houses, distances between houses and shopping malls, parks ctc.

Figure 17.5: Screenshot of an Urban Master Plan Design

The behaviows Several decision tables relate qualitative statements with real figures. For example, the decision table on house types resulting in a lot size is reused. Other examples are street type information that is rclatcd to the amount o r piirking spaces and road capacity. The niles are mainly used to aggregate information. For example, calculalion o r llie amount of buildings, parking spaces, roads, shopping malls, water demand, area usage etc., at the precinct lcvcl are derived from all the elements (regions, streets etc.).

The neighbowhood DSS All the site elements, such as shopping malls, streets, commercial regions and residential regions, arc visunliscd in the 2D viewer (Figure 17.6). By selecting an individual object or selecting multiple objects, properties such as house type can be changed. Changing the house type will influence the amount of houses, the amount of people, thc water demand, the density etc. These changes are directly reflected in the charts that provide an overview of the Lotal precinct.

154

Figure 17.6: Screenshot of the Demand Support System at the Neighbourhood Level

CONCLUSIONS Two different deinand support systems have been created by developing two different ontologies and behaviours. Tlic inaster plan and the neighbourhood demand support systems demoiistrate how ontology-driven applications call be used, and how [hey caii be customised for project-specific necds. The ontology approach allows modelling of what is imporhiit at the stage the project is in. Froin a tcchiiicitl perspective, it is clear that the ontology approach supports sonic softwarc rctise. Individual clcineiits of the ontology can be reused in similar situations. Conceptually, the ontologics bccomc a sort of toolkit thal caii be used to develop a new project-specific ontology. Obviously it is hoped that this toolkit will cxpaiicl so Lhal custom-built DSSs become possible. As a dcmaiid support system can be built up “on-site”, tlie next step is to get involved in a real project ancl build a customised DSS.

REFERENCES Australian Model Code for Residential Development (AMCORD). 1992. Gzridelir7es.for. Urban Ifotrsbig. Canberra:

RGPS. CRC for Co~i.s/r’uc/io~i Imovo/ion. 2005, Coris/,victioti 2020: A vision fbr Atis/rdia ’s pi*operty and coris/rtrciiorr

i/idus/i:v. litti~://www.coiistrticlioii-iiiiiovatioii,iiifo (accessed I 2 April 2006). Gruber, T. 1995, Towards principles for the tlcsigii of ontologies used for knowledge sharing. h~iervn~ionnl Jo7irrinl of H u / 1 ? ~ 7 1 7 arid CoinpziIcr Sluclies, 43 (5/6): 907-928.

Klein, M. 2002. Conibbi0ig mid Re/a/irig Oiifologies: ,411 aiio!ysis qfprablmis and soD~tions. Amsterdam: Vrije Uiiivcrsiteit.

Kiitibla~ich, 11. 2003. An AI tool for the real world: knowlcdge modeliiig with Protdgd. JovoWorId, 20 June: littr,://www.iavaworld.co1n/invaworld/iw-06-2003/iw-0~20-protere.litml? (accessed 29 May 2006).

Schcvers, 1-1. 2004. Demnu‘ S ~ p p ~ i Sy.s/ems: PhD rhesis. Netherlands: Delft University of Technology. Sowa, J. 2000. KrioMhdge Re~ireseii/otioiw. California: BrooksKole Publishing Company. Stanford Medical Informatics (SMI). 2000. The PI-ore‘ggd Pmjecl httu:l/nro~cee,stunford.edu (accessed April 2006). Zeisel, J. I98 I. 67qzriry by Design. California: Cole Publishing Coiiipnny.

155