Enhancing building product libraries to enable the dynamic definition of design element...

16
Engineering, Construction and Architectural Management 2000 7 4, 373 – 388 Enhancing building product libraries to enable the dynamic definition of design element specifications JASON UNDERWOOD*, MUSTAFA A. ALSHAWI ² , GHASSAN AOUAD ² , TERRY CHILD & IHSAN Z. FARAJ § *School of Civil Engineering, University of Leeds, Leeds LS2 9JT, UK, ² School of Construction and Property Management, University of Salford, Salford M79NU, UK, AremisSoft Corp., Technology House, Lissadel Street, Salford M66AP, UK, § Building Research Establishment, Watford WD27JR, UK Abstract The AIC Research Group at the University of ject partners’ businesses. This paper presents the devel- Salford has been involved in a government-funded pro- opment of the specification application that aims to demonstrate the potential for such technologies to en- ject that has resulted in the development of an inte- grated multi-user distributed construction project hance the specification process, enabling design ele- database through the implementation of next-generation ments to be specified directly from a building product Internet technology together with Product Data Technol- database Web site. Keywords design element specifications, IFC, inte- ogy - WISPER. The objective of the project was to develop a working system capable of demonstrating the grated distributed construction project database, three- tier client – server architecture, STEP Part 21 physical file future direction of information integration with the pro- INTRODUCTION The Internet, with its open standards and accessibility is fast, evolving into a powerful environment for sup- porting distributed group work. Originally, the Inter- net was a static two-tier client – server unidirectional environment for the publishing and broadcasting of electronic documents. However, demand for dynamic content is beginning to change this. The Internet is evolving from a publishing technology into a full- blown client – server medium, with the potential to run line-of-business applications and to deal with the com- plex requirements of multi-step business-to-business and consumer-to-business transactions, i.e. e-com- merce (Orfali et al. 1997; Pountain & Montgomery 1997). This is being further enhanced with the emer- gence of XML (W3C 2000) and more recently XML vocabularies for electronic business for the Building and Construction industry such as aecXML (Bentley 2000) and BCML (Building-Construction Markup Language). In conjunction with Internet technology, which pro- vides the capability for distributed working, Product Data Technology (PDT) supports the definition and processing of information pertinent to a product throughout its design and operational life. It is a concept to capture and communicate the product defi- nition in a digital form without ambiguity or loss of data throughout the life cycle of a product—within or between enterprises. PDT is based on international standards providing an ‘open data paradigm’ where business critical information is not locked with a par- ticular system. Product Models such as STEP AP225 (ISO 10303 ‘STEP’ 2000; STEP AP225 2000), IFC (IAI 2000), CIS (CIS 2000), etc., have been devel- oped to establish exchange protocol specifications in various engineering domains, e.g. architecture, build- ing, etc. Furthermore, toolkits have emerged to sup- port the exchange and storage of data specified by these product models such as STEP Tools ST-Devel- oper, EPM Express Data Manager, etc. This paper presents the specification application that has been developed as part of the implementation of a new generation of construction integrated environ- ments. The application aims to demonstrate the poten- tial for next-generation Internet technology together with PDT to support the direct specification of design elements from a product database Web site. Such an application enables the designer to retrieve their defined specifications (including technical informa- tion) in a standard format directly via the Web, and to upload this information into the project database to be accessed by the other applications, e.g. CAD, estimat- ing, etc. In addition, the paper provides a brief overview of the integrated distributed construction en- vironment, the implemented supporting applications and the IFC Object (product) Model architecture. © 2000 Blackwell Science Ltd 373

Transcript of Enhancing building product libraries to enable the dynamic definition of design element...

Engineering, Construction and Architectural Management 2000 7 � 4, 373–388

Enhancing building product libraries to enable the dynamicdefinition of design element specifications

J A SON UNDERWOOD*, MUSTAFA A. ALSHAWI†, GHASSAN AOUAD†, TERRY CHILD‡ &IH SAN Z . FARAJ§

*School of Civil Engineering, University of Leeds, Leeds LS2 9JT, UK, †School of Construction and PropertyManagement, University of Salford, Salford M7 9NU, UK, ‡AremisSoft Corp., Technology House, Lissadel Street, SalfordM6 6AP, UK, §Building Research Establishment, Watford WD2 7JR, UK

Abstract The AIC Research Group at the University of ject partners’ businesses. This paper presents the devel-Salford has been involved in a government-funded pro- opment of the specification application that aims to

demonstrate the potential for such technologies to en-ject that has resulted in the development of an inte-grated multi-user distributed construction project hance the specification process, enabling design ele-database through the implementation of next-generation ments to be specified directly from a building productInternet technology together with Product Data Technol- database Web site.

Keywords design element specifications, IFC, inte-ogy - WISPER. The objective of the project was todevelop a working system capable of demonstrating the grated distributed construction project database, three-

tier client–server architecture, STEP Part 21 physical filefuture direction of information integration with the pro-

INTRODUCTI ON

The Internet, with its open standards and accessibilityis fast, evolving into a powerful environment for sup-porting distributed group work. Originally, the Inter-net was a static two-tier client–server unidirectionalenvironment for the publishing and broadcasting ofelectronic documents. However, demand for dynamiccontent is beginning to change this. The Internet isevolving from a publishing technology into a full-blown client–server medium, with the potential to runline-of-business applications and to deal with the com-plex requirements of multi-step business-to-businessand consumer-to-business transactions, i.e. e-com-merce (Orfali et al. 1997; Pountain & Montgomery1997). This is being further enhanced with the emer-gence of XML (W3C 2000) and more recently XMLvocabularies for electronic business for the Buildingand Construction industry such as aecXML (Bentley2000) and BCML (Building-Construction MarkupLanguage).

In conjunction with Internet technology, which pro-vides the capability for distributed working, ProductData Technology (PDT) supports the definition andprocessing of information pertinent to a productthroughout its design and operational life. It is aconcept to capture and communicate the product defi-nition in a digital form without ambiguity or loss ofdata throughout the life cycle of a product—within or

between enterprises. PDT is based on internationalstandards providing an ‘open data paradigm’ wherebusiness critical information is not locked with a par-ticular system. Product Models such as STEP AP225(ISO 10303 ‘STEP’ 2000; STEP AP225 2000), IFC(IAI 2000), CIS (CIS 2000), etc., have been devel-oped to establish exchange protocol specifications invarious engineering domains, e.g. architecture, build-ing, etc. Furthermore, toolkits have emerged to sup-port the exchange and storage of data specified bythese product models such as STEP Tools ST-Devel-oper, EPM Express Data Manager, etc.

This paper presents the specification application thathas been developed as part of the implementation of anew generation of construction integrated environ-ments. The application aims to demonstrate the poten-tial for next-generation Internet technology togetherwith PDT to support the direct specification of designelements from a product database Web site. Such anapplication enables the designer to retrieve theirdefined specifications (including technical informa-tion) in a standard format directly via the Web, and toupload this information into the project database to beaccessed by the other applications, e.g. CAD, estimat-ing, etc. In addition, the paper provides a briefoverview of the integrated distributed construction en-vironment, the implemented supporting applicationsand the IFC Object (product) Model architecture.

© 2000 Blackwell Science Ltd373

374 Underwood, J. et al.

DEVELOPMENTS IN BUILD ING PRODUCT

L I BRARIES

The industry is witnessing a shift in the medium usedto publish manufactured product information. Ini-tially, the traditional paper-based catalogues weretransferred to digital CD-ROM based services. Severalof these services are available in the UK such as:

� Barbour Index: an integrated database of regulatory,technical and product information.

� Technical Indexes (http://www.techindex.co.uk/):source for technical data, product/supplier informa-tion, standards and regulations for commerce andindustry worldwide.

� ASC Disk Index: a database of suppliers and manu-facturers of construction products and services. In-formation is accessible via CI/SfB classification,common arrangement, products, suppliers, andtrade names.

� RIBA Product Selector and Product Selector Plus(http://www.ribac.co.uk/frameset.htm): source forinformation on manufacturers and suppliers ofbuilding products and services, advisory organiza-tions, and trade names. It also has cross-referencesto Agrement Certificates, WIMLAS Certificates andBritish Standards, including Quality Assuranceapprovals.

Subsequently, a number of systems are being madeavailable online over the Internet such as:

� The Building Information Warehouse (http://www.biw.co.uk/): a developing database of on-lineinformation and a showcase for integrated productspecification with design drawings/co-ordinatedmodels viewed over the web.

� ASC Web Index (http://www.ascwebindex.com/):the site provides access to two databases of informa-tion on building products and services—UK andInternational. In addition, the site provides links tomanufacturers’ web sites, alphabetical indexes ofproducts and suppliers, and a sophisticated searchengine.

� Certified Products (http://www.certifiedproducts.org/): a web catalogue with search features for find-ing specific products or locating companies carryingproducts within North America that have been cer-tified by the Forest Stewardship Council (FSC is anindependent, non-profit making organization thatsets the standard for environmentally and sociallyresponsible forest management).

� RIBA Product Selector Online (http://www.productselector.co.uk/): a searchable index ofUK manufacturers that is designed to provideproduct and contact details, so that national andinternational specifiers alike can access this informa-tion anywhere in the world. Individual manufac-turer listings also provide gateways tomanufacturers’ own web sites with furtherinformation.

� Building FOCUS (http://www.building-focus.co.uk/): building FOCUS is a starting point forinformation users in the building industry. It hasbeen designed to incorporate all relevant informa-tion sources that are of use to the building industrysuch as product, technical and complimentary ser-vices information. The intention is for individuals tomove outwards from Building FOCUS into a cus-tomized and well signposted building environmentweb universe. As a result Building FOCUS givesfaster access to information on manufacturers andcontractors, comprehensive coverage of standardsand appropriate governing bodies, and ease of ac-cess to other building related web sites.

However, at best these services in the main simplyduplicate the process required to use a paper cata-logue, i.e. the systems are not enhanced with theinclusion of product parameters and associated files,whilst the majority of these services merely provide adirectory of product manufacturers’/suppliers’ details.

Recently, there have been many initiatives that havefocused on the implementation of advanced informa-tion technologies to demonstrate the potential for in-ter-disciplinary/organizational working throughout thelife cycle of a construction project, i.e. concurrentengineering. Either as part of these initiatives, or as aspin off from them, the area of enhancing on-linebuilding product libraries to facilitate the supplierchain and to compliment a concurrent engineeringenvironment is beginning to receive attention (CON-CUR 2000; Newnham et al. 1998).

WISPER - WEB-BASED INTEGRATED

SHARED PROJECT ENVIRONMENT

Three-tier client–server architecture

As shown in Fig. 1, the architecture of WISPER usesa three-tier client–server infrastructure to demonstratethe integration between detailed design, specificationdefinition, building element based cost estimating, andconstruction scheduling. This is in addition to aVRML viewer that allows the graphical querying of a

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

375Dynamic definition of design element specifications

project database (Alshawi et al. 1998, Faraj et al. 1998;WISPER 2000; Faraj et al. 1999). Within a three-tierarchitecture each facet of the application, i.e. presenta-tion (user interface), logic (processing), and data stor-age (database), is isolated. The presentation facettypically has buttons and other control devices thatactually change data. The interface layer provides theuser with a mean to interact with the system and e.g.input data, manipulate data, visualize information, etc.Further, different users (organizations) can change theinterface to suit their needs without effecting otherpart of environments or other users. These interfacecomponents communicate with the logic facet of theapplication. The logic tier makes decisions regardingthe quality of the data, how things should be entered,and what information is essential. The logic tier is thereal ‘meat’ of an application and is the actual facet thatdescribes a business, more so than any other facet.The logic facet communicates with the data storagefacet. The data storage facet takes the decisions madeby the logic facet and actually does something withthem, altering data in some way. Isolating each facet ofan application provides benefits such as maximum

control, scalability, and flexibility. In terms of control,the data is protected by isolating the databases fromthe users altogether. Only the application servers canaccess the databases, and all requests for data gothrough the application servers. As the bulk of thecomplex code resides on the application servers in theform of objects, so they are easier to maintain, modify,and improve. A three-tier architecture decreases theload on the database by off loading some of the dataconcerns to the application servers. Each object in theapplication server can, in theory, be moved to its ownserver. Therefore, performance can be improved with-out rewriting code, i.e. making the application signifi-cantly more scalable. Finally, a three-tier architectureis much more flexible. With all the logic residing in theapplication servers, replacing the databases with differ-ent versions is much easier as a result of a less applica-tion-specific code being in the database. In addition,the application is virtually client independent, becausethe only thing residing on the client machines is theuser interface elements and basic code for communi-cating (Campbell 1997; Orfali et al. 1997; Pountain &Montgomery 1997).

Figure 1 Overview of WISPER.

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

376 Underwood, J. et al.

IFC Object-Oriented Project Database

At the lowest level of the system architecture (bot-tom tier), the main project database has been devel-oped using the ObjectStore OODBMS together withthe implementation of Java classes derived directlyfrom the final version 1.5 of the IAI IFCs. The IAIis a non-profit building industry alliance of organiza-tions developing a common language for technology toimprove the communication, productivity, deliverytime, cost, and quality throughout the design, con-struction and maintenance life cycle of buildings. Itsgoal is to define, promote and publish the commonlanguage (IFC) as a basis for information sharingthrough the project life cycle and across disciplinesand technical applications (IAI 2000). The objectmodel for the final version 1.5 of the IFCs has beenpublished using EXPRESS. EXPRESS is a formallanguage developed by the STEP community for thedescription of data models (STEP Tools, Inc. 2000a;UKCIC 2000). To map this schema to ObjectStore,ST-Developer was used to convert the IFC schemafrom EXPRESS to a set of programming languageclasses (pure Java classes). ST-Developer is a StepTools product that provides a comprehensive, stand-alone set of software development tools for handlingthe complexities of the STEP standard, which canbe used to build software that works with STEP datain Object-Oriented databases, relational databases,and traditional files (STEP Tools, Inc. 2000b). Ob-jectStore utilities are then used to read the Javaclasses to create the IFC project database schema.This schema can then be used and instantiated bythe various construction applications.

Application servers

Web client–server technology has been adopted inthe form of Netscape WAI Web Server Extensionsapplications written in Java for the two-way exchangeof information between the project database and ex-isting software, i.e. AutoCAD, Excel, MS Projectscheduling package, etc. (Middle Tier). WAI is aCORBA-based programming interface that definesobject interfaces to the HTTP request/response dataand server information. Using WAI, Web applica-tions can be written to accept HTTP requests froma client (Web browser), process them, and return theresponse to the client. The end user does not needto know where the data resides or which server isprocessing it (Netscape 2000).

User interface

Finally, the top tier of the system provides the inter-face to the overall system. The user interface has beenimplemented as a set of Web pages and other commer-cial applications to support the different constructionexperts that may need to interact with the environ-ment. The user interface enables the user to submit,retrieve, process and manipulate data. Users can per-form operations on the project data by selecting theappropriate menu item on a specific Web page. Eachmenu item references a URL that submits an HTTPrequest to the server. The Web server assigns theresponsibility for processing the HTTP request to theCORBA objects.

WISPER takes advantage of open Internet standardsand uses the concept of a ‘project Web site’ as a firstpoint of access for all shared project information. Eachnew project has its own Web site, allowing projectinformation to be accessed through an internal net-work (Intranet) or through the wider global Internet.Furthermore, existing security mechanisms such aspassword protection, certificates, IP address filtering,etc., ensure the security of the project information bycontrolling access to the project Web pages.

Implemented applications

� CAD (design): as a result of the lack of availablecommercial IFC compatible CAD systems, the re-search team has implemented their own CAD sys-tem that uses the AutoCAD-14 geometry engine.The application supports both newly created andexisting projects. The ‘newly created project’ appli-cation enables the user to create new building de-signs and to share information with otherconstruction applications. Data in the application issaved in STEP Part 21 file format. The ‘existingproject’ application allows the user to populate thedatabase from a STEP Part 21 physical file. Part 21physical files of existing projects can, therefore, beloaded to the database for amendment and saved asPart 21 physical file format.

� VRML: the application generates the VRML modelof the design and displays the results within a Webbrowser. The user can interact with the design andretrieve other construction data associated with theobject or project as a whole that are found in thedatabase from the virtual reality model.

� DWF: DWF is a graphics format for the transfer ofdrawings over Intranets and the Internet. The appli-cation parses the database for the building elements

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

377Dynamic definition of design element specifications

Figure 2 IFC Object Model architecture and layering concept (IAI 2000).

that exist in a project and generates the DWFrepresentation of each element.

� Estimating: generates the elemental IFC cost groupobjects within the central project database from thedesign, before returning this information into Excel.The user add costs to the cost groups in Excel anduploads the CSV file into the project database, i.e.adding costs, date and time, etc. to the previouslygenerated cost group objects. Finally, a cost sum-mary of the project can be viewed in terms of bothelement type and storey.

� Planning: generates the work group objects withinthe central project database from the design, beforereturning this information into MS Project schedul-ing package. Next, the user adds duration and links/dependencies and uploads the CSV file into theproject database, i.e. adding the durations and links,to the previously generated work group objects.

I F C PROPERTY TYPE DEF IN IT IONS AND

SHARED PROPERTY SETS

IFC Object Model architecture overview

The IFC Object Model architecture provides a modu-lar structure for the development of model compo-nents, the ‘model schemas’. The architecture consists

of four conceptual layers, which use a strict referencinghierarchy (Fig. 2). Within each layer a number ofgrouped modules (model schemas) exist (IAI 2000).

� Independent resource layer: independent resourcesform the lowest level in the IFC Model architectureand can be used or referenced by classes in otherlayers. Resources can be characterized as generalpurpose or low-level concepts or objects, which donot rely on any other classes in the model for theirexistence. All resources represent individual busi-ness concepts. For example, all information con-cerning the concepts of cost is collected within thecost subset of the IfcPropertiesResource schemaand any classes within the other layers which needto use cost will reference this resource. Similarly, allideas concerning geometry are collected togetherwithin the IfcGeometryResource.

� Core layer: the core forms the next layer in the IFCModel Architecture. Classes defined here can bereferenced and specialized by all classes in the Inter-operability and Domain/Application layers. TheCore layer provides the basic structure of the IFCObject Model and defines most abstract conceptsthat will be specialized by higher layers of the Ob-ject Model. The Core includes two levels of abstrac-tion: the Kernel and the Core Extensions. The

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

378 Underwood, J. et al.

Kernel provides all the basic concepts required forIFC models within the scope of the current IFCRelease. The Kernel also determines the modelstructure and decomposition. Concepts defined inthe Kernel are, necessarily, abstracted to a highlevel. The Kernel also includes fundamental con-cepts concerning the provision of objects, relation-ships, type definitions, attributes and roles. TheKernel can be envisaged as a kind of Meta Modelthat provides the platform for all model extensions.The constructs that form the Kernel are verygeneric and are not AEC/FM specific, althoughthey will only be used for AEC/FM purposes as aresult of the specialization by Core Extensions. TheKernel is the foundation of the Core Model. Kernelclasses may reference classes in the IndependentResource layer but may not reference those in theother parts of the Core or in higher-level modellayers. Core Extensions provide extension or spe-cialization of concepts defined in the Kernel. CoreExtensions are the first refinement layer for abstractconstructs, extending Kernel constructs for usewithin the AEC/FM industry. Each Core Extensionis a specialization of classes defined in the Kernel.Beyond this class specialization, primary relation-ships and roles are also defined within the CoreExtensions. A class defined within a Core Extensionmay be used or referenced by classes defined in theInteroperability or Domain/Applications layer, butnot by a class within the Kernel or in the Indepen-dent Resource layer.

� Interoperability layer: the interoperability layer pro-vides modules that define concepts or objects com-mon to two or more Domain/Application models.The commonly used ‘common object’ modules en-able interoperability between different domain orapplication models. Such an architecture supportsthe outsourcing of Domain Model developmentwhilst retaining control over the key structuring andframework requirements of interoperability.

� Adapter definitions: the concept of an ‘adapter’, al-though not yet used in the current IFC release, isforeseen to access various domain models, includingdisperse models, i.e. those defined outside the IAI.The main requirements for Adapters are the facilita-tion of:1. Direct Plug-In of IFC developed Domain Mod-

els, which directly reference or use Core defini-tions (this is currently the only appliedtechnique).

2. Plug-In of externally developed, non-harmo-nized, Domain Models via a mapping mecha-

nism down to Core and Interoperabilitydefinitions.

3. Establish an interdomain exchange mechanismabove the Core to enable interoperability acrossdomains including a container mechanism topackage information.

� Domain/applications layer: Domain/ApplicationsModels provide further model detail within thescope requirements for an AEC domain process or atype of application. Each is a separate model thatmay use or reference any class defined in the Coreand Independent Resource layers. Examples of Do-main Models are Architecture, HVAC, FM, Struc-tural Engineering etc.

Type definitions

The IfcPropertyTypeResource defines the basic capa-bilities for Property definitions that can be attached toobjects and relationships. This Resource module en-ables a ‘type’ of an element to be defined, which inturn establishes a standard to be used many times in aproject. A standard type is established through thedefinition of a set of properties or characteristics thatwill be held constant for all occurrences in the projectmodel. Therefore, a single record of these attributes isassociated with the Type Definition object rather thanwith each occurrence of the element.

For example, in the case of doors and windows, anIfcPropertyTypeDef object is created for each type ofelement and is referenced by those IfcObjects, e.g.IfcDoor, IfcWindow, etc., to which it is associated(Fig. 3). The IfcPropertyTypeDef class provides forthe capability to define a set of properties at runtime,as they do not need a separate static class definition,and share the values of the set of properties amongmultiple instances of the same class of objects. Inaddition, the IfcPropertyTypeDef class possesses anumber of attributes. ‘TypeDefName’ represents thename of the specific Property Type Definition,‘TypedClass’ refers to the name of the class for whichthe object defines a type, e.g. IfcDoor, IfcWindow, etc.and ‘GenericType’ specifies the IFC generic type des-ignation, e.g. SingleSwing, FixedCasement, etc.

Shared property sets

Each type definition has a reference to an IfcShared-PropertySet. An IfcSharedPropertySet defines a set oftype driven properties (and is, therefore, defined aspart of the IFC standard) that are shared by multipleinstances of a semantic object, i.e. each semantic ob-

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

379Dynamic definition of design element specifications

ject instance (having the same property values) sharesby reference a single instance of the IfcSharedProp-ertySet with particular property values.

The type definition for a single swing door has areference (in the Sharedproperties attribute) to a‘Pset–DoorSglSwing’ shared property set, that in turn,has references to two further shared property sets,‘Pset–DoorType’ and ‘Pset–DoorPanel’, that are heldin the ‘Hasproperties’ attribute list (Fig. 3). The‘Pset–DoorType’ shared property set contains thecommon shared values/properties for the specific typeof single swing door. These properties relate to infor-mation such as the reference ID for the door typewithin a particular project, specific description of thedoor type, manufacturer, nominal and rough heightsand widths, fire, thermal and acoustic ratings, whetherthe door is designed for use in exterior walls, etc. Eachproperty is created as IfcSimplyProperty object. Ifc-SimpleProperty defines an attribute class in which theunique description/name of the property (‘Descriptor’)and a reference to the property’s value (‘ValueCompo-nent’) is held. The actual value of the property is heldin an IfcMeasureValue object (part of the IfcMeasur-eResource module) based upon its type, e.g. Ifcde-scriptivemeasure, Ifcnumericmeasure, Ifcnumeric-measure, etc.

The properties associated with the doorframe suchas description, depth, thickness, etc. are also containedwithin a shared property set (‘Pset–DoorWin-

FrameType’), which is referenced in the ‘Hasproper-ties’ attribute list of the ‘Pset–DoorType’ sharedproperty set. Again, a simple property and associatedmeasure value object represents each of the properties.An IfcMaterial object represents the material propertyof the doorframe. IfcMaterial is part of the Materialmodel within the IfcPropertyResource module thatprovides the facility to specify the material from whichan object is composed. The IfcMaterial property to-gether with the simple properties is referenced in the‘Hasproperties’ attribute of the ‘Pset–DoorWin-FrameType’ shared property set.

Finally, the ‘Pset–DoorPanel’ shared property setcontains the properties (or references to simple andmaterial property objects) for the door panel/leaf asso-ciated with the single swing door type definition, e.g.height, width, thickness, material, etc.

In a similar manner, the type definition for a fixedcasement window has a reference to a ‘Pset–Fixed-Casement’ shared property set, that in turn, has areference to a further shared property set, ‘Pset–Win-dowType’. The ‘Pset–WindowType’ shared propertyset contains the common shared values/properties (ref-erences to simple property objects) for the specific typeof fixed casement window, e.g. ID reference, descrip-tion, manufacturer, dimensions, etc. The ‘Pset–Door-WinFrameType’ shared property set for the windowframe is also referenced in the ‘Hasproperties’ attributeof the ‘Pset–WindowType’ shared property set.

Figure 3 Type definitions and shared property sets.

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

380 Underwood, J. et al.

Figure 4 Schematic overview ofthe specification definition WAI ap-plication.

PRODUCT DATABASE

For the purpose of the prototype, a product relationaldatabase was developed using MS Access. Relationaldatabases store data in a flat structure that is suited tothe storage of product data, more so than OODBMSs.Furthermore, relational databases are more widelyused in industry than OODMSs and posses a struc-tured query language (SQL) that enables complexsearches to be carried out. The information relating toeach particular type of product is held in a single tablewithin the product database, i.e. Door Frames, DoorLeaves, and Windows. The structure of each table isprimarily based upon the properties specified in theIFC property sets, i.e. Pset–DoorPanel, Pset–DoorType, Pset–DoorWinFrameType, Pset–Win-dowType, etc. For example, the Door Leaves tablecomprises fields relating to information such as manu-facturer, product name, height, width, thickness, mate-rial, fire, thermal and acoustic ratings, suitability forexternal or internal exposure, etc. In addition, theDoor Leaves and Windows tables have a field to holda reference to an image file of each specific product.

SPEC IF ICAT ION WEB SERVER

EXTENSION APPL ICAT IONS

The Specification application has been implemented astwo Netscape WAI Web server extension applicationswritten in Java. The first application enables the defin-ition of door and window specifications from the sup-

pliers database, which are generated as IFC typedefinitions in the form of a STEP Part 21 physical file,i.e. an EXPRESS-driven data exchange file specifica-tion (STEP Tools, Inc. 2000b, UKCIC 2000). TheIFC type definition Part 21 exchange files are up-loaded into the IFC Object-Oriented Project Data-base, via the second of the WAI applications.

Each WAI application creates and registers CORBAobjects (OMG 2000) with the respective Web server,i.e. suppliers database and IFC project database. TheWeb server associates each of these objects with aspecific URL of the form: http://server//iiop/object–name. The server part of the URL identifies the nameof the machine on which the Web server runs, whileiiop (Internet Inter ORB Protocol) passes request orservice replies through the internet, and the object–name is the name by which the application is registeredand identified by the ORB. Once the URL is accessedthe Web server delegates the responsibility for process-ing the HTTP request to the CORBA objects.

Specification definition WAI application

Figure 4 shows an overview of the specification defini-tion WAI application. The application receives an ini-tial ‘search’ request from the search criterions webpage of the specific product, i.e. single swing doors,fixed casement windows, etc., via the HTTP POSTprotocol. The search criterions Web page enables thesearch of a specific product based on a number ofcriterions such as manufacturer, height, width, mate-

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

381Dynamic definition of design element specifications

rial, and in the case of doors, external or internalapplication. Based upon the search criterions re-ceived in the request, the application takes the neces-sary action. In the case where amanufacturer/supplier is not specified within the re-quest, the application connects to the product data-base via JDBC and ODBC, and retrieves thosemanufacturers/suppliers that manufacture/supplyproducts matching the search criterions. JDBC is aJava API for executing SQL statements on relationaldatabases. Via the ODBC API, JDBC enables Javaprograms to establish a connection with a relationaldatabase, send SQL statements, and process the re-sults (Sun Microsystems, Inc. 2000). The applicationgenerates a dynamic HTML page presenting themanufacturers/suppliers received from the SQLquery and incorporating hypertext links for viewingtheir products. In addition, the initial search criteri-ons are created as hidden input types within theHTML page. Each ‘View Products’ hypertext linkallows for a further request to be sent via the HTTPGET protocol. Upon receiving such a request, theapplication connects to the products database, andretrieves information such as product description,image file name, etc., for the products of the se-lected supplier that match the initial search criterionspassed in the request. The application uses this in-formation to dynamically generate a catalogueHTML page of the specific products, which it subse-quently returns. On the other hand, where a manu-facturer/supplier is supplied within the initial ‘search’request, the application connects to the productsdatabase, retrieves the necessary information for theproducts that match the search criterions, and gener-ates a dynamic catalogue HTML page of the specificproducts, before returning the page.

In the case of windows, a catalogue of windowunits is returned. However, from the point of view ofdoors, the application initially returns a catalogue ofdoor leaves. Within the HTML catalogue page, eachspecific product’s description is created as a hyper-link to a client–side JavaScript function. Client-sideJavaScript statements embedded in an HTML pagecan respond to user events. When a particularproduct is selected from the catalogue HTML page,the JavaScript function copies the product’s descrip-tion into the respective text input form element onthe definition Web page, i.e. ‘Window’ or ‘DoorLeaf’ input box. Following the selection of a doorleaf, and the subsequent copying of its descriptioninto the ‘Door Leaf’ text box, the JavaScript functiontriggers a request to the application to return a cata-

logue HTML page of door frames suitable for thedoor leaf selected. The application uses the door de-scription passed in the request to retrieve the de-scriptions of the suitable door frames from thedatabase, before dynamically generating the catalogueHTML page, including client-side JavaScript, etc.,and returning the page. In a similar manner to thedoor leaf catalogue, when a door frame is selectedfrom the catalogue web page the description of thedoor frame is copied into the ‘Door Frame’ text in-put form element of the single swing door type defi-nition Web page.

As each type definition/specification is defined thespecified element type’s reference (the reference IDproperty of the ‘Pset–DoorType’/‘Pset–Window-Type’ shared property set) and the descriptions ofthe selected product(s) associated with the elementtype are passed in a request to the application. Theapplication holds the element type reference togetherwith the descriptions of the associated product(s) foreach specification until requested to generate thePart 21 physical exchange file, i.e. providing the op-portunity for additional type definitions to bedefined.

Once requested to generate the Part 21 exchangefile, the application connects to the product databaseand retrieves the various properties associated withthe product(s) specified for each type definition, e.g.dimensions, supplier, fire rating, material, etc. ST-Developer uses the EXPRESS IFC schema and thecorresponding IFC Project Database schema (Javaclasses), together with the properties retrieved fromthe product database to generate the complete IFCType Definitions for those specified. The completeIFC Type Definitions are written out to a Part 21physical file, which is returned.

Type definitions upload WAI application

Figure 5 illustrates a schematic overview of the typedefinitions upload WAI application. This applicationresides on the project database Web server. Part 21physical exchange files of defined type definitions aresent to the application via a file input form elementusing the HTTP POST protocol, which are subse-quently uploaded to the IFC Project Database. ST-Developer uses the IFC schema and thecorresponding IFC Project Database schema to cre-ate the Java objects that correspond to the projectinstances defined in the Part 21 physical file. UsingObjectStore utilities, the Java objects are instantiatedin the IFC Project Database.

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

382 Underwood, J. et al.

Figure 5 Schematic overview of thetype definitions upload WAI applica-tion.

APPL ICAT ION SCENARIO

The first point of access to the environment is via theWISPER home page. From this page a list of projectsthat exist in the project database can be viewed byauthorized project team members (controlled by the

project manager) or alternatively the projects that havebeen created can be deleted (by the project manager).The list of projects page enables the project managerto create/set up a new project or other authorizedproject team members to view a list of designs associ-ated with a specific project. Similarly, the list of de-

Figure 6 Design main menu.

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

383Dynamic definition of design element specifications

Figure 7 Single swing door specification page.

signs page allows a new design to be created by anauthorized member of the design team. By creating anew design or selecting a design from the list, the mainmenu page for the design is opened (Fig. 6). From thispage the individual applications, i.e. design, estimat-ing, planning, VRML, specification, etc., can be ac-cessed via their respective Web page.

The specification menu option is selected in order todefine the specifications for the design. From the mainspecification page menu the specification page for aparticular type of design element is accessed, e.g.single swing door, fixed cased window, etc (Fig. 7).The specification page for each specific design elementpage is comprised of the specification main menu, adefinition page and the search criterions page (Fig. 7).The search criterions Web page enables a search to beconducted for specific products based on a number ofcriterions such as manufacturer, height, width, mate-rial, and in the case of doors, external or internalapplication. Using these search criterions, the projectdesign team can identify products that match theclient’s/design requirements from which to specify thedesign. In the case where the manufacturer search

criteria is not specified, a list of the manufacturers/sup-pliers that supply the products which meet the searchcriterions are returned. By selecting one of the manu-facturers/suppliers a catalogue of the their productswhich meet the search criterions is returned. Alterna-tively, where a manufacturer/supplier is specified thena catalogue of the appropriate products is returned.The catalogue initially returned for single swing doorscontains door leaves while the fixed case windowscatalogue presents window units. A particular productis selected from the catalogue and in doing so theproducts description is copied into the respective textinput form element on the definition web page, i.e.‘Selected Door Leaf’, ‘Selected Window’, etc., (Fig.8). Once a door leaf has been selected then a catalogueof the appropriate door frames is returned. A doorframe is selected from the catalogue and its descriptionis subsequently copied into the ‘Selected Door Frame’text input form element. Within the definition Webpage the element type reference for the specification isdefined, i.e. the reference ID property of the ‘Pset–DoorType’/’Pset–WindowType’ shared property set(Fig. 8).

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

384 Underwood, J. et al.

Figure 8 Fixed casement window definition and catalogue pages.

Once each type definition/specification has beendefined, i.e. the element type’s reference has beendefined and the product(s) associated with the elementtype has been selected, it is defined to the serverapplication via the ‘Define Prop Set’ menu option. Indefining the type definition/specification with theserver application, the type reference and the associ-ated product description(s) are held by the serverapplication. At this stage additional type definitions/specifications can be specified and defined to theserver application.

Following the definition of the necessary type defini-tions/specifications the ‘Generate Type Defs’ menuoption is selected to download a Part 21 exchange fileof the type definitions/specifications (Fig. 9). This fileis initially downloaded to the local machine beforebeing subsequently uploaded to the project databasevia the ‘Upload Type Defs’ page which in turn isaccessed from the main specification page menu.

Once the type definitions/specifications have beendefined and uploaded to the project database thesethen become accessible to the other design team mem-bers. The designer downloads them to their local

machine via the ‘Download Part 21’ menu option onthe design main menu page, imports them into theirCAD application and attaches the relevant type defini-tions/specifications to the design elements during theCAD session (Fig. 10). The design, together with therelevant (attached) type definitions/specifications, isthen exported from CAD to Part 21 exchange fileformat before being uploaded to the project databasevia the ‘Upload Part21’ page accessed from the designmain menu page. As the design evolves within theproject database members of the project team and inparticular the client can remotely view and interrogate(the VR model of the project). Furthermore, the de-sign information becomes available (remotely) for thegeneration of the project schedule and estimate. Thisproject management information, i.e. time and cost is,in turn, uploaded to the project database, making itaccessible to authorized members of the project team.

USE OF THE ENVIRONMENT

It is perceived that project managers could be a focalpoint in using the distributed computer integrated

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

385Dynamic definition of design element specifications

Figure 9 Example typedefinition Part 21 physicalexchange file.

environment and would be responsible for ensuringsmooth progress of work across the project’s stages.Project information is carefully monitored and con-trolled by the project management organization whereit applies its own experience and rules to run theproject effectively. The latter implies that such organi-zations might have their own databases and businesslogic that need to be accommodated in any integratedsolution. This role can be facilitated by the introduc-tion of the project management site. The site can bebased at and controlled by the project management

team although it behaves as any other site in that itstores and exchanges project information with othersites. It acts as a repository for project informationwhere:

� Multiple data versions of each discipline are auto-matically stored as and when they are released bytheir owning sites.

� Authorized practitioners from any discipline canaccess the data as and when required.

� Each transaction between the site and others islogged.

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

386 Underwood, J. et al.

Figure 10 Attaching door ‘type definitions’ within CAD.

� Other related/authorized sites are automatically in-formed of any new forthcoming versions of data.

� Communication between the project managementsite and other sites is carried out through the Webserver.

CONCLUSIONS

This paper has presented a specification applicationthat has been developed as part of the implementationof a new generation of computer integrated environ-ments. The integrated multi-user distributed construc-tion project database environment, WISPER, is basedon a three-tier client–server architecture, in which theuser interfaces, business logic and database are all keptseparate. The development of the Object-OrientedProject Database has been achieved via the implemen-tation of the IFC final version 1.5 Object Model. Inaddition, Internet technology was used to develop theuser interfaces and enable the communication of dis-tributed applications, i.e. Web pages and Web serverextensions, respectively.

The specification application aims to demonstratethe potential for design elements to be specified di-rectly from a product database Web site—enhancingthe specification process. From the specification Webpages on the project Web site, the user can search forspecific products based on several criterions. From thedynamically generated catalogue of searched products,the user is then able to select products directly fromthe catalogue and define the required specifications.Finally, the user requests the product database Webserver extension application to return a Part 21 physi-cal file of the IFC Type Definitions for the specifica-tions defined, which is subsequently uploaded into theIFC Project Database to be downloaded by the CADapplication and attached to the respective design ele-ments. Enhancements to building product librariessuch as those presented in this paper would create acloser link between suppliers and the design process—bringing supplier information early to the design pro-cess. Resulting benefits could include reducing thespecification production time and eliminating the du-plication of specification information, in turn improv-

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

387Dynamic definition of design element specifications

ing the accuracy. There is also the potential for suppli-ers/manufacturers being able to influence the design,e.g. costs.

REFERENCES

Alshawi, M., Aouad, G., Faraj, I., Child, T. & Underwood, J.(1998) The implementation of the industry foundationclasses in integrated environments, CIB W78 Conference,Sweden, August,, pp. 55–66.

Bentley (2000) aecXML: procuring project communications forA/E/C http://www.aecxml.org/.

Campbell, R. (1997) Middleware and architecture: it all endsin tiers. Application Development Advisor, 1(2), 56–58.

CIS (2000) CIMsteel integration standards. http://www.cis2.org/.

CONCUR (2000) Concurrent design and engineering in Build-ing and Civil Engineering, http://ivope.ivo.fi/concur/.

Faraj, I., Alshawi, M., Aouad, G., Child, T. & Underwood, J.(1999) Distributed object environment: using internationalstandards For data exchange. Computer-Aided Civil andInfrastructure Engineering, 14, 395–405.

Faraj, I.Z., Alshawi, M.A., Aouad, G., Child, O. & Under-wood, J. (1998) The implementation of the IFC in adistributed computer integrated environment, Second Eu-ropean Conference on Product and Process Modelling in theBuilding Industry, Watford, UK, October., pp. 19–21.

IAI (2000) International Alliance for Interoperability, http://interoperability.com/.

ISO 10303 ‘STEP’ (2000) Welcome to ISO TC184/SC4 devel-opers of international industrial data standards, http://www.nist.gov.sc4.

Netscape (2000) Writing web applications with WAI, http://de-veloper.netscape.com/docs/manuals/entrprise/wai/index.htm.

Newnham, L., Amor, R. & Parand, F. (1998) Gaining qualitymanufactured product information through ARROW, PDTdays, BRE Watford, March.

Orfali, R., Harkey, D. & Edwards, J. (1997) CORBA, Java,and the Object Web. BYTE, 2, 95–100.

OMG (2000) OMG: Object Management Group, http://www.omg.org/

Pountain, D. & Montgomery, J. (1997) Web Components.BYTE, 22, 56–68.

STEP AP225 (2000) Application Protocol 225: AP 225building elements using explicit shape representation, http://www.haspar.de/Ap225/index–eng.htm

STEP Tools, Inc. (2000a) The ISO STEP Standards, http://www.steptools.com /library/standard/

STEP Tools, Inc. (2000b) ST-Developer, http://www.steptools.com/products/stdev/.

Sun Microsystems, Inc. (2000) JDBC–connecting Java anddatabases, http://www.steptools.com/products/stdev/

UKCIC (2000) STEP–ISO 10303, http://www.ukcic.org/step/step.html

W3C (2000) Extensible Markup Language (XML) 1.0, http://www.w3.org/TR/REC-xml

WISPER (2000) Welcome to WISPER: Web IFC basedshared project environment, http://www.aic.salford.ac.uk.pit/

APPENDIX A

List of abbreviations

AEC/FM Architecture, Engineering, Constructionand Facilities Management

AIC Automation and Integration inConstructionComputer-Aided Draughting/DrawingCADDrawing Web FormatDWFFacilities ManagementFM

HVAC Heating, Ventilation and AirConditioning

IAI International Alliance forInteroperability

ODBC Open Database ConnectivityOODBMS Object-Oriented Database Management

System

Notes of explanation

(Application Protocol) Complex dataAPmodels used to describe specificproduct-data applications. APs de-scribe not only what data is to be usedin describing a product but also howthe data is to be used in the model.(Application Protocol Interface) AAPIspecification for the interface of a soft-ware package by which other pro-grams can utilize that package.(CIMsteel Integration Standards)CISOpen standards for the digital ex-change and sharing of the engineeringinformation relating to a structuralsteel framework. One of the many re-sults to emerge from the CIMsteelpan-European Eureka 130 projectconcerned with improving the effi-ciency and effectiveness of the Eu-ropean Constructional SteelworkIndustry both through the harmonisa-tion of design codes and specifica-tions, and through the introduction ofComputer Integrated Manufacturingtechniques for the design, analysis,detailing, scheduling, fabrication,erection and management functions.(Common Object Request Broker Ar-CORBAchitecture) An industry standard tech-nology infrastructure for systemsintegration and distributed comput-ing.

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388

388 Underwood, J. et al.

(Comma Separated Values) A text fileCSVthat uses commas to separate valuesand line-end characters to separaterows. Typically used as an inter-change format between spreadsheetapplications and simple flat-file data-bases.(HyperText Markup Language) TheHTMLcoding language used to create Webpages. HTML is a collection of tagsor codes you put in a document tocreate a Web page. The tags do every-thing from formatting text (boldface,font size, etc.) to creating links toother Web pages.

HTTP (HyperText Transfer Protocol) Theprotocol for moving hypertext filesacross the Internet. Requires a HTTPclient program on one end, and anHTTP server program on the otherend.(Industry Foundation Classes) An ob-IFCject model that provides a formal spe-cification for the data that can beshared by AEC/FM and software de-velopment professionals.(Object Request Broker) The centralORBCORBA component that functions asa communication infrastructure,transparently relaying object requestsacross distributed heterogeneous com-puting environments.(Structured Query Language) A ven-SQLdor neutral query language for ex-tracting information from relationaldatabases.

(Standard for the Exchange ofSTEPProduct Model Data) A series of stan-dards currently under developmentwithin the international Standardiza-tion Organisation (ISO). Launched in1983, ISO/STEP is a very ambitiouslong-term project to develop co-ordi-nated data exchange and informationsharing standards that span all sectorsof engineering, based on ProductModelling concepts.Part 21 of STEP (ISO 10303) spe-STEP Part 21cifies an exchange structure formatusing a clear text encoding of productdata for which the conceptual modelis specified in the EXPRESS lan-guage. The file format is suitable forthe transfer of product data amongcomputer systems.(Uniform Resource Locator) The ad-URLdress used to identify the location ofWeb sites, Web pages, and other re-sources on the Internet.

VRML (Virtual Reality Markup/ModellingLanguage) A language that describes3-dimensional objects. Used on theinternet to create ‘virtual worlds’.(Web Application Interface) A pro-WAIgramming interface that enables de-velopers to extend the functionality ofNetscape web servers.(eXtensible Markup Language) AXMLgeneralized markup language basedon SGML (Standard GeneralizedMarkup Language), with some influ-ences from HTML, aim primarily atthe Web.

© 2000 Blackwell Science Ltd, Engineering, Construction and Architectural Management 7 � 4, 373–388