Integration of CAD, Product Model and Distributed Building ...

Integration of CAD, Product Model and Distributed Building Component Databases M. Sun TIME Research Institute, University of Salford, Salford, M7 9NU ([email protected]) F. Parand Building Research Establishment, Garston, Watford, WD2 7JR ([email protected])

ABSTRACT: In recent years, R&D in the field of Product Data Technology (PDT) has resulted in a consensus on the use of integrated data model for achieving data sharing between multiple AEC software applications. Several such integrated data models have been or are being developed. Now research efforts are gradually shifted to how to adapt existing applications to these emerging models. This paper describes an architectural CAD prototype originated from the Computer Models for the Building Industry in Europe (COMBINE) project. The CAD system is developed by integrating the COMBINE Integrated Data Model (IDM) and “offthe-shelf” AutoCAD system so that building models can be instantiated in the IDM database. It is also linked to distributed Building Component Databases (BCD) to enable building material and product data to be imported directly into the CAD application over the Internet. 1 INTRODUCTION During a building life cycle, many tasks require the collaboration of a multi-disciplinary team including architect, engineer, consultant, contractor, etc. Each member of this team is responsible for certain aspects of the project. Different professions use their own unique processes to undertake their tasks, but often have to rely on information supplied by others. At present, the communication problem between the team members is often a cause for project delay and building defects. Improving the communication link has been identified as crucial to further efficiency gain in construction (Latham 1995). With the wide use of AEC software (CICA 1997), the traditional cross discipline communication is increasingly manifested as an issue of data exchange and data sharing between different software applications. This issue has been the main focus of PDT research during the last couple of decades. So far, there is a consensus on the need of developing a neutral data format and its use as a data exchange medium between all the AEC applications. This neutral format is usually known as integrated data model or building product model. In recent years, there have been several well known models, for example the RATAS model (Enkovaara 1988), the Building Core Model (Wix 1996), the Integrated Data Model of COMBINE project (Dubois 1995), the Integrated Product Model of COMBI (Scherer 1995) and the Logical Product Model for CIMSteel (Watson 1995). The latest effort in data modelling is focused on the IAI’s Industry Foundation Classes (IAI 1997). As data modelling technology matures, it is reasonable to assume that a

stable integrated data model or models will emerge soon. The next formidable challenge the research community will face is how to adapt the existing AEC applications to the new data model. This paper describes an integrated architectural CAD (ArchCAD) prototype which was originated from the EU COMBINE project. It demonstrates that a customised AutoCAD can be integrated with an integrated data model. The resulted CAD system is able to create building models in accordance with the COMBINE IDM in object oriented databases. CAD acts as the front end tool to instantiate and manipulate building models in the database. Furthermore, it is linked to remote building component databases so that building material and product data can be imported on-line. 2 DATA MODEL AND DATA INTEGRATION 2.1 The importance of Data Model The ability to communicate has been fundamental to many human activities. The success of inter-personal communication depends not only on the medium that makes the communication possible, but also on the receiver’s ability to understand the message. To ensure correct understanding of the message, a prior agreement is necessary between the message sender and receiver on the symbols used to carry the message and the meaning of these symbols. During the construction process, the project team members are able to communicate with each other because they share a common understanding of the meaning

of the communication mediums, i.e., drawing conventions, specification standards, etc. When it comes to the communication between software applications, the same principle applies. Two applications involved in the communication need to share the same data format or at least understand each other’s data format. Historically, because most of the software packages are developed by different vendors, they all have their own particular data format. To achieve data exchange, a data mapping mechanism is required between two applications. Given the large number of applications used throughout the building life cycle, it is impractical to set up one-to-one mapping between all of them. A more efficient solution is to use a neutral data format as a medium for the data exchange (Howard 1989). This neutral data format is an integrated data model which captures the full semantics of a building system and its components. In this approach, each application only works with a subset of the model. This subset is often described as an aspect model. Data exchange can be achieved between all the aspect models by mapping through the integrated data model. 2.2 COMBINE Integrated Data Model The Integrated Data Model (IDM) is the conceptual data model for the COMBINE project. Since COMBINE is an energy conservation oriented project, the scope of the IDM covers, but not limited to, site and climatic data, building spatial relationships, elemental construction specification, building shape description, HVAC installations, as well as energy related performance aspects. ISO-STEP EXPRESS has emerged as the de facto standard data modelling language. It is adopted for the COMBINE data modelling task. In accordance with the EXPRESS formalism, the IDM is modelled using concepts such as SCHEMA, TYPE, ENTITY, ATTRIBUTE, etc. In all, IDM contains 42 schema and some 300 entity and type definitions. Detailed description of the IDM can be found in a number of references (Dubois 1995; Nederveen 1995). This paper only intends to give a brief introduction to the shape modelling aspect, because it is relevant to the CAD integration described later. The physical shape of a building is important project data used for many evaluation and simulation tasks. Shape description covers two aspects, geometry and topology. Geometry is about dimensional information, length, width, and coordinates, while topology is positional relationship between different elements of a shape. Because most existing CAD applications are graphic centric, their data structure is largely geometry oriented. Geometry has also been the main focus of international data standardisation. ISO-STEP has well defined geometry model but no stable topology model.

Given the COMBINE domain, a pure geometry shape description is not sufficient to support all its applications. Consequently, the IDM adopted a cellular topology model known as Relational Model representation (RM-rep). Nederveen (1993) and Augenbroe (1994) discussed the main features of RM-rep which can be summarised below: • Main concepts: The main concepts of RM-Rep include cell, face, edge, and vertex. Cell is used to represent a space. A cell is bounded by faces; and a face is bounded by edges; and an edge has a starting and finishing vertex. • Side information: Although the face in RM-Rep has a zero thickness, it is still modelled as having two sides. The side information is represented explicitly so that orientation and direction can be referred without further complicated geometry calculation. In addition, the face-sides objectify the relationship between cell and face. They can then be used to attach for instances solar irradiation data. • Adjacency: Since faces can be cell-cell boundaries, adjacency of cells is captured by shared faces, face-face adjacency by shared edges etc. • Inclusion: The RM-rep is able to explicitly define face-face inclusions, e.g. representation of a window inside of the representation of a wall. • Orientation: The orientation of RM-rep entities is a mixture of explicit references to an orientation vector in the case that the geometry provides no orientation information. RM-rep is far more complex than the data structure of the “off-the-shelf” CAD, such as AutoCAD. This semantic gap has serious implications for the integration between the two. 2.3 Data Integration Strategy There are two options to achieve data integration using the IDM: 1. to exchange data directly between two applications using IDM as the mapping reference model. 2. to implement the IDM as an integrated project database and use it as a central data repository and data exchange hub. Adopting the first option implies that every application maintains data locally. As a result, the same project information would have to be stored in different places. This will be a potential cause for data inconsistency and error in communication. An integrated project database will allow all the project information to be stored in one location, which is easier to ensure its consistency. Therefore, COMBINE adopted the second integration option. An additional benefit of this choice is that it provides system integration potential as well as data integration.

Figure 1 COMBINE data integrated strategy

STEP files On-line CAD

IDM instantiation/ manipulation visualisation

Building model

mapping

Sub-schema

stripping

Off-line AEC Applications

meshing

Database

The project further devised two interaction methods between AEC applications and the IDM database, “off-line” and “on-line” (Figure 1). “Off-line” interaction refers to the data exchange between the central database and AEC applications operating remotely. It involves a bi-directional data mapping, using ISO-STEP files as the medium, between the IDM global view of a building and a partial view required by an application. The process of importing data from the application into the IDM database is referred to as "meshing", because it merges a partial model into a richer model. On the other hand, the process of exporting data to an application is referred to as "stripping", since it maps from a richer view of a building to a partial view and some entity types and relationships need to be stripped off. “On-line” interaction is the process that CAD application accesses the IDM database directly to instantiate building models and manipulate the stored data in the database. 3 FROM DATA MODEL TO BUILDING MODELS

By examining the building life cycle, it is not difficult to conclude that dimensional and material data are the most essential data of a building model. Traditionally, hand drawings are used to create, store and communicate this project information. Over the last few decades, graphic centric Computer Aided Design (CAD) software has replaced drawing boards. The current generation of CAD offers 2D drafting, 3D modelling, visualisation and animation by manipulating graphic objects such as point, line, face, solids, etc. It can be argued that CAD only has a partial view of the building model because designers, engineers and builders have to work with more complex objects, such as buildings, spaces, walls, windows, constructions, etc. COMBINE aims at bridging this semantic gap by integrating an “off-the-shelf” CAD tool with IDM. The objective is to develop an Architectural CAD (ArchCAD) tool that is capable of creating building models in the full semantics of the IDM. With resource constraint, ArchCAD is not intended to be a full blow object oriented CAD system. It is rather a hybrid solution by integrating existing technologies of CAD, data modelling and object oriented database (Figure 2).

3.1 Integrated Architectural CAD Figure 2 Integration of CAD, data model and ODB COMBINE IDM provides a conceptual structure for the building data to be stored and exchanged. Before any data exchange can take place a building model has to be created in the IDM database. At present, the information needed for creating such a model is held in various sources. Unless there is a major reengineering of the construction practice, building project information will continue to be generated by different disciplines using different AEC applications. Therefore, in order to gain acceptance by the industry for the IDM, tools are required which enable the users to migrate existing project information to the IDM format.

ArchCAD

CAD • 2D, 3D drawing • Graphical editing • Visualisation

Building Data Model • Design objects • Data semantic • Constraints

OODB • Persistency • Concurrency • Version • Transaction

The advantages of this approach are: It allows the users to retain their familiar ways of using the existing CAD packages during the design stages. • It enables the users to migrate design data from existing CAD drawings to a building model in compliance with the COMBINE IDM schema, and populate the IDM database so that data exchange can take place with other AEC applications. • It enhances the CAD to deal with semantically richer building objects, e.g., building spaces, walls, windows, instead of merely graphical entities, e.g., solids, faces, lines and points. • It stores information as objects in an object oriented database with full support for concurrent engineering, design history, object versioning, etc. •

3.2 System Implementation Architecture AutoCAD and Objectstore (Object Design, 1993) database have been chosen for the implementation of the ArchCAD prototype. To achieve development efficiency, a hierarchical configuration was adopted for the implementation of the CAD integration. There are four common layers in this architecture, of which three are functional layers and one communication interface layer (Figure 3). Figure 3 ArchCAD integration architecture

AutoCAD AutoCAD Extension

CAD Application Program Interface IDM objects behaviour (e.g. space volume) IDM objects creation, deletion, and navigation Objectstore database layer

The first layer is Objectstore database which provides application schema initialisation, and services for object versioning, locking control, etc. At this level, all objects are treated the same and the semantics of IDM schema are not needed. On top of the database layer is a layer that handles generic object creation, deletion and navigation in the COMBINE context. The implementation of this layer requires the interpretation of the IDM schema as well as object composition knowledge. The third layer is ‘IDM objects’ geometrical and topological behaviours. Typical examples are the transformation of co-ordinates, calculating surface areas or space volumes. These three layers together define the

functions needed by the CAD tools for the IDM objects. Both AutoCAD and Objectstore support C++ programming environment, the interaction between the AutoCAD and the IDM database could be achieved by sharing C++ objects in computer memory. However, the project intends to provide a generic integration interface for other CAD systems, i.e., Intergraph Microstation, which may have a different programming platform. A layer of CAD Application Program Interface (API) was introduced, which defines the standard protocols through which CAD integration functions can be called. With this layer, each CAD tool is able to use their own way of communicating with the IDM. The implemented ArchCAD expands the data semantics from merely graphic objects in AutoCAD to COMBINE IDM objects. It enables AutoCAD to work with semantic richer data structure and store data directly in the IDM database. The native AutoCAD functions are used only as a graphical user interface. For example, when a user wants to create a Room object, he or she may draw a rectangle using AutoCAD command. In the background, a series of objects are initialised in the database. They include the room object itself, walls, ceiling and floor objects that bound the room, geometrical and topological objects representing their shapes, etc. The object creation rules are defined in the second layer of the system configuration (Figure 3). After all the objects are created, a link is established between the rectangle object in AutoCAD and the room object in the database. 3.3 Model Instantiation Within the scope of COMBINE, the targeted ArchCAD tool is not a design tool in a sense that it is not intended for designers to draw building layout from scratch although it is possible. Instead, it is a tool for designers to translate their existing designs into a building model in accordance with the IDM schema. It is acknowledged that in the absence of a common standard for CAD drawing, users may have diverse and personalised conventions in using AutoCAD. Drawing attributes, such as layers, colours, line styles, blocks, etc., are used quite randomly by different users to represent semantic concepts. Therefore, it is impossible to automate the process of initialising building model directly from CAD drawings produced by users. ArchCAD uses three conceptual layers (not AutoCAD layer) to translate a building from a user drawing to a data model in an IDM database (Figure 4). • AutoCAD layer. In this layer, the user has complete freedom to generate AutoCAD drawings. All CAD styles and conventions can be used, and the semantic knowledge is with the user. • ArchCAD layer. From the information on the AutoCAD layer and the knowledge to interpret it, a set of drawings are generated

Figure 4 Building model instantiation procedure AutoCAD layer AutoCAD layer Users may use all Users may use all AutoCAD functions AutoCAD functions freely. freely.

The model initialisation functions also include a generic editor which is able to create instances of any IDM entity type. Its main purpose is to fill any “gaps” in the model so that other AEC applications may get a valid model from their point of view. 3.4 Model Manipulation

This room is drawn as a polyline of 8 vertices.

ArchCAD layer ICAD layer Users re-trace their Users re-trace their drawings according to drawings according to pre-defined conventions. pre-defined conventions.

The task of model manipulation is limited to moving and resizing windows. This is achieved by a combination of native AutoCAD commands and defined behaviours of IDM objects. The action of events for moving a window is as follows: 1. Use AutoCAD command to select the graphic which represents the window to be moved. Then, a message is sent to the IDM database to identify the window object and its representing geometrical/topological objects in the database. 2. The IDM database requests information of new coordinates for the window which is entered using AutoCAD command. 3. The IDM performs modifications on the appropriate attributes of the objects in the database. 4. AutoCAD retrieves the updated coordinates information from the database and redraws the window. 4 BUILDING COMPONENT DATABASE

IDM layer IDM Data arelayer created and Data in are created and stored accordance stored with IDM.in accordance with IDM.

•

through restricted use of AutoCAD commands and according to explicit rules defined. These rules include elementary spaces being drawn as polylines and windows and doors as lines with vertical dimension as extended data, etc. IDM layer. Once the drawing on the ArchCAD layer is completed, it is ready to be translated into building model and stored in IDM database. During this process, all the IDM objects are created and the semantic information is added. For example, it will determine the adjacency of spaces, relationships between building elements, location of windows and doors, etc. After the model is initialised in the IDM database, the information on the other two layers is discarded. ArchCAD will retrieve data from the initialised IDM database to draw the building at specified decomposition level.

With the ever-increasing use of computers, more and more building component data become available in electronic form. However, at present many of them are just scanned images of the traditional product catalogue. Although CD-ROMs or on-line network are better dissemination media, the current product information is not in a ready to use format for other AEC applications. Architects and engineers alike still have to re-draw the components or extract technical data for evaluation tasks. To address this issue, product data should be stored in databases in stead of scanned images. Learning from past experience, it is unwise to let individual manufacture to decide the data format of their product databases. Otherwise, the incompatibility problem will occur between these databases and between the database and the AEC applications. The objective of Building Component Database (BCD) is to define a framework which allows building component information to be stored and imported directly into CAD, design and analysis applications. The benefits will be easier access to the these data by users and better maintenance by the information providers. 4.1 Database Structure Since the emphasis of the COMBINE project was energy and HVAC design, the BCD structure is rich

Figure 5 ArchCAD link to distributed BCD databases User

BCD Web Server AutoCAD

WWW Browser

CAD API

BCD API

Third party software

HTTP/ BCD API

BCD Databases

Internet WWW, MS Winsock

ADS extension HTTP/ BCD API

Project Database

BCD Web Server Objectstore OODB, Integrated Data Model

BCD Databases

of data that is needed for such purposes. However, the BCD structure contains a number of non-energy related data, e.g., cost, ordering information, manufacturer information, updating of data etc. In developing the structure for the BCD a number of considerations have to be taken into account: • The data model of BCD should be consistent with the IDM so that its data can be easily used in the COMBINE system. • The data structure should be flexible to suit both manufactured product and custom-built product. • The main components that are considered for inclusion in the BCD database are: wall, roof, floor, ceiling, cladding, window, window and door frame, door, structural element, stairs, material. A data model is developed for the BCD database. All the objects descend from the top IDM objects, therefore, inherit their behaviours. It also allows other types of building fabric as sub-type of these entities. The sub-type will define some specialised characteristics while inheriting all data of the existing type.

are clients. There can be many BCD servers and each server can manage more than one component database. The physical link between the client and server is the Internet. The interaction requires that the clients be able to query the BCD databases and to download data in an appropriate format. To meet this demand, two communication protocols are used (1) HTTP, and (2) a purpose built, MS-Winsock based BCD API. The use of these protocols will be discussed in section 5.1.

4.2 Client/Server Implementation

5.1 Communication Protocol

Because of the complex and hierarchical nature of the BCD data model, it was decided to use an object oriented database system, ObjectStore, for its implementation. A graphic interface is developed for the database administrator or other authorised users to enter component data into the database. Once in the database, the component data are stored permanently until being deleted or modified by the administrator. These BCD databases are located remotely from the ArchCAD application. A distributed client/server system architecture is adopted for their interaction (Figure 5). The BCD is the server, ArchCAD and other processes that need to access these databases

Microsoft Windows Socket (Winsock) is a well established, TCP/IP supported, network communication protocol. It enables two computers exchange data through messages. Figure 6 illustrates how it is used for the communication between ArchCAD and BCD server. The BCD databases are managed by a WWW server. The user can use standard WWW browsers to browse and search these databases. This query is done through HTTP and standard WWW implementation. Once a product is identified, structured data need to be transferred from the BCD server to the ArchCAD client. The task involves data

4.3 Latest Development Within the scope of COMBINE project, the BCD work was mainly aimed as proof of concept. Since then, development in this area has been taken forward in a new project at BRE, the ARROW project. For the latest information of the ARROW project the reference (Newnham 1997) can be consulted. 5 IMPORTING DATA FROM DISTRIBUTED BCDs

Figure 6 BCD communication protocol Web Browser/ CAD

query BCD server

Application Layer

Wall

IDM Object Layer

has BCD API support, it is able to restructure the binary data as exchange objects. Then, these objects can be mapped to IDM objects which in turn can be linked to other objects in the IDM model. 5.2 Use Scenario

Wall

Ex_Wall

Winsock packets

Winsock messages

Ex_Wall

BCD API Layer

Winsock packets

MS Winsock Layer

transforming through four layers on both the server and client sides (Figure 6). BCD Server side: First of all, the component object is loaded from the database into computer memory. Because the data structure of BCD objects is virtually the same as that in the IDM, there is no action needs to be taken. Next task is to map the BCD objects to Exchange Objects at the BCD API layer. These objects are very similar to BCD objects, but they descend from MS Windows socket object therefore inherit the cross network communication behaviours. After that, a communication link, called socket, is established and these exchange objects can be automatically streamed onto packets of messages and sent to the client side. ArchCAD client side: The sequence of events is in reverse order on the client side. The data come from the BCD server as winsock packets. In the packet stream, there is embedded knowledge of how to interpret the data. Because the ArchCAD client also Figure 7 User interface

The sequence of using ArchCAD and BCD server is as follows: 1. Start AutoCAD. The user starts by creating a new drawing or loading an existing drawing. 2. Load the ArchCAD ADS extension program. This will give the user extended functions. 3. Follow the procedure described section 3.3 to instantiate a building model in the IDM database and populate the geometry and topology data. 4. Select the building elements (walls), using AutoCAD object selection methods, for which the construction type will be attributed (Figure 7). 5. Establish a link to BCD server by selecting ArchCAD menu item “Link to BCD”. A WWW browser will start up and enable the user to browse or search the BCD database. 6. Once a component object is selected, the user can trigger the process of importing data from BCD server to ArchCAD by clicking a “ArchCAD link” button. 6 CONCLUSIONS With continuing advances in the PDT field, a stable integrated data model will emerge. COMBINE and other research projects have proved the concept of using such a model and integrated project database to achieve data integration in the AEC industry. However, the semantic gap between the integrated

model and domain specific AEC applications will likely remain for a long time. The described ArchCAD prototype demonstrated how this gap can be bridged by integrating existing technologies. The use of BCD database is a feasible way to distribute technical data of building products. However, the COMBINE experience shows that gathering data and populating BCD databases are very time consuming tasks. The latest ARROW project seeks to develop a toolkit for manufactures to enter their own data. The ARROW prototype is currently being piloted with real manufacturers’ data. ACKNOWLEDGEMENT The work described in this paper is part of the COMBINE project funded by the EU Commission as part of the JOULE program. The BCD work by BRE was funded by Department of the Environment, Transport and the Regions in the UK. The authors would like to acknowledge the contribution of other colleagues in the COMBINE project.

REFERENCES Augenbroe G. & W. Rombouts 1994. Extended topology in building design systems, ASCE First Congress on Computing in Engineering, Washinton D.C. 1196-1203. CICA 1997. Construction Industry Computing Association – Software directory, CICA, Trust Court, Vision Park, Histon, Cambridge, CB4 4PW, UK Dubois A.M., J. Flynn & et al 1995. Conceptual modelling approaches in the COMBINE project, in Scherer R.J. (Eds.), Product and Process Modelling in the Building Industry, A.A. Balkema, Rotterdam:555-565 The model itself is available at: http://dutcu15.tudelft.nl/~combine/idm/index_schema .html

Enkovaara E., M. Salmi & A. Sarja 1988. RATAS project, Computer aided design for construction, published by Building Book Ltd., Helsinki, Finland Howard H.C., R.E.Levitt & et al 1989. Computer integration: reducing fragmentation in AEC industry, Journal of Computing in Civil Engineering, No. 3, 1989:18-32. IAI 1997. Guidelines for the development of industry foundation classes, IAI, May 1997 Latham M. 1995. Constructing the Team, Final report of the government/industry review of procurement and contractual arrangements in the UK construction industry Nederveen S. 1993. IDM+ release, Topology and Space/Enclosures, COMBINE Internal report. March 1993.

Nederveen S. 1995. COMBINE Task 2 Final Report. This document can be downloaded from: http://dutcu15.tudelft.nl/~combine/document/task2.zip

Newnham L, F. Parand & et al 1997. CIB W78 Workshop on Information Technology Support for Construction Process Re-Engineering, IT-CPR97, Cairns, Australia, 9-11 July 1997. See also: http://cig.bre.co.uk/arrow_demo/test/

Object Design 1994. ObjectStore release 3.0 User Guide Scherer R.J. 1995. EU-project COMBI – Objectives and overview, in Scherer R.J. (Eds.), Product and Process Modelling in the Building Industry, A.A. Balkema, Rotterdam:503-510 Watson A. & A. Crowley 1995. CIMSteel integration standard, in Scherer R.J. (Eds.), Product and Process Modelling in the Building Industry, A.A. Balkema, Rotterdam:491-493. Wix, J. 1996. Computerised exchange of information in construction. Building Construction core model. Paper is available at: http://www.bre.co.uk/bre/research/cagroup/consproc/i tra/bccm/news/news5.htm