Data exchange system for an integrated building design system

ELSEVIER Automation in Construction 6 (1997) 147-155

Data exchange system for an integrated building design system ’

Ming Sun a, * , Stephen R. Lockley b

a Department of Surveying, Saljord University, Saljord M7 9NlJ, UK b Department of Architecture, Newcastle Uniuersity, Newcastle upon Tyne NE1 7RU, UK

Abstract

The main feature of an integrated building design system is data integration or data sharing by all design tools in the system. It is achieved by developing an integrated data model that combines different views of the building so that, through it, information can be exchanged in electronic form. This paper describes a Data Exchange System which provides the underlying support for data exchange and data maintenance in an integrated building design system utilising object-oriented database and ISO-STEP technologies. 0 1997 Elsevier Science B.V.

Keywords: Data exchange; Integrated building design system: CAD; Building data model; Design tool

1. Introduction

Building design usually involves a team of archi- tects, engineers, and other specialists, each of whom is responsible for certain aspects of the design. They often work concurrently on the same project and information has to be exchanged between them to reach a coherent design. At present, the information exchange is often done using paper-based media, such as documents and drawings, owing to the lack of integration between tools used by individual members of the design team. This approach is time consuming and error-prone because the same data needs to be entered repeatedly. Recent advances in computing technology and research in integrated applications offer potential Information Technology (IT) solutions to this problem. The Computer Models

* Corresponding author. ’ Discussion is open until December 1997 (please submit your

discussion paper to the Editor on Architecture and Engineering, Y.E. Kalay).

for the Building Industry in Europe (COMBINE) project was funded by the European Commission to investigate computer applications as means to im- prove the practice of the building industry, especially design practice [l]. Its main aim was to explore a computer-based Integrated Building Design System (IBDS) capable of supporting the multi-tasking and interactive nature of the building design process.

The two main objectives of COMBINE are: firstly to develop an Integrated Data Model (IDM) as a common schema for describing building objects [2]; secondly to achieve data integration or the sharing of data by all tools in one system through the IDM. A prototype system was developed in the first phase of the project between 1990 and 1992, which consisted of several design tools and an Integrated Data Model. It successfully demonstrated the data exchange prin- ciples between tools. However, the implementation of the IDM was done in a very much ad-hoc fashion, and data exchange control was rather limited. ISO- STEP physical file format was used as both data storage and exchange media.

In the second phase of COMBINE (1993-1995),

0926.5805/97/$17.00 0 1997 Elsevier Science B.V. All rights reserved. PII SO926-5805(97)00015-O

148 M. Sun, S.R. L.ockley/Automation in Construction 6 11997) 147-155

data transaction control and system management were addressed as one of the main tasks. The development of a data exchange system was part of the effort.

2. Data exchange requirements

There are two possible approaches to achieve data exchange between any two tools in a system. First is a direct interface approach in which a dedicated exchange link is set up between two tools. To build this link, one has to identify the data which need to be transferred and the format to be used for the transfer. The advantage of this approach is that it is relatively simple especially when the number of tools in the system is limited. Its weakness is the lack of system extendibility. When a new tool is added to the system, an interface link needs to be built between the new tool and each and every existing one. The alternative approach is to use a common data model and shared data repository. In this approach, the data exchange between tools is done through the common data model. Each tool only needs to maintain an interface with the model, subsequently the number of links is greatly reduced. Its strength lies in its ability to handle a large number of tools and the inclusion of new tools. The COMBINE project aimed at exploring data exchange strategies between as many existing design tools as possible. Therefore, the second approach was adopted.

The COMBINE Integrated Building Design Sys- tem comprises a series of computer software Design Tools, and off-the-shelf architectural CAD tools. Fig. 1 illustrates its system architecture the components of which include a data exchange kernel, on-line CAD tools and off-line design tools. The data exchange kernel stores building information in a framework defined by the Integrated Data Model. The on-line CAD tools are responsible for initialising building models and providing graphical visualisa- tion of the models. The off-line tools are existing software tools for thermal simulation, lighting design, cost estimation, building regulation checking, etc. All design tools maintain data exchange interface with the kernel, and the kernel and its data interaction with the design tools defines the domain of the COMBINE Data Exchange System (DES) the

Product data

On-line To& technology tools

.-- ; _.*- f . . Off-line Tools

Fig. 1. COMBINE IBDS Architecture, after Augenbroe [3].

main functional requirements of which can be sum- marised as follows.

2. I. Persistent building model

Building design is a long process during which information about the building is enriched gradually. The first requirement for the DES is to hold a persistent model for different states of the building.

2.2. Design tool interface

The philosophy of COMBINE is to re-use not to re-engineer existing design tool applications in an integrated framework. The second requirement for the DES is to support the design tool data exchange interface through the use of product data technology.

2.3. View integration

In COMBINE, each design tool deals with a particular aspect of the design problem, thus, it has a partial view of the building model. These partial views need to be merged into a single coherent building model in the central data repository. This determines the requirement to maintain a consistent building model and to support the growth or popula- tion of this model through the integration of partial views.

2.4. Change management

In a real world design project if the architect feels the need to make changes to the building layout, he or she would inform the HVAC engineer to halt the

M. Sun, S.R. L.ockley/Automation in Construction 6 (1997) 147-155 149

heating and cooling system work, since they would have to be re-designed as a result of the building geometry changes. In a computer-based design support system, a degree of concurrent engineering management is expected. This determines the requirement of the DES to provide the underlying support for change management and conflict prevention.

2.5. Design versioning

An essential feature of any design process is the requirement to explore alternative design solutions. Design versioning should allow each designer to take a version of the design at any stage. These versions will develop independently and co-exist. They also need to be merged to produce one coherent version of the design.

2.6. Design history

As a design develops it is also necessary to keep track of these versions so that, at any point, it is possible to review the design history trail, to re-ex- amine the decision making process and to rollback to an early consistent state of the design. This mechanism is also needed to allow the comparison of alternative design options. This defines the requirement to audit the evolution of the building design or to manage the design history.

3. Data exchange kernel

The purpose of the Data Exchange Kernel is to store not only building objects information but also functional object information. In addition to the building data, the Kernel has knowledge of the data scheme used to interpret the building data, design tools that operate on the building objects, and changes caused by individual tools.

To meet the functional requirements, the Kernel needs the support of a robust object-oriented database system. After a review of the existing systems, Ob- jectstore [4] by Object Design was chosen as the implementation platform. Three strategies were considered for the implementation of the Kernel. 1. An early binding solution in which the IDM

schema is implemented as C + + classes.

2. A late binding solution which implements a generic data store and exchange service without dependence on any application schema.

3. A combination of an early and late binding implementation. The first option is, at first sight, perhaps the most

obvious, as all the entities of the IDM have a one-to- one mapping to C + + classes. The resulting structure is easy to read and object behaviours can be implemented for each entity type to manage its interaction with other entities. i.e. a “Wall” entity could have the behaviour to determine the area of “windows” it contains. Unfortunately this would

produce a kernel which is not only dependent upon the schema of the IDM but also has embedded knowledge that is specific to a view of the model. As a matter of practical consideration, the IDM was not fixed at the start of the COMBINE project. It had been evolving and changing throughout the project life cycle. In an early binding approach, every change in the IDM schema would result in the need of re-implementation for the Kernel.

The second option is a late binding approach. Since the primary function of the data exchange kernel is to store data and exchange data with design tools, it does not need to know the semantics of the data. For instance, it could treat a building object and a Cartesian point object in the same way. Semantic knowledge of the data being exchanged resides in the design tools. Interpretation of the data can be done at the point when they are exported to design tools. However, the kernel has to store the information needed for the interpretation to take place. In order to do this, apart from the value of the data, information about its type needs to be stored. In this approach, because data typing is not coded at compi- lation time, it is called a late binding approach. The advantage is that the Kernel provides a generic data store and management service. Its implementation and use do not depend on any particular data schema, and it is able to handle any data model as long as its schema conforms to the ISO/STEP EXPRESS standard [5].

The main advantage of the early binding is that it defines the data semantics explicitly so that on-line data exchange can be carried out directly. Its disad- vantage is the need for re-engineering when the data definition or the schema changes. However, the ad-

150 M. Sun, S.R. Lockley/Automation in Construction 6 (1997) 147-155

vantage of late binding is that it is schema indepen- dent and the schema is stored as data so that it can be manipulated to facilitate the data exchange task. Its main constraint is the lack of explicit definition of the data structure in the Kernel. A late binding solution would work well for the off-line data exchange. Because the exchange takes place through a neutral medium, data interpretation has to be performed at both sides no matter how the Kernel is implemented. For the on-line data integration, the late binding approach introduces extra complications. By definition, on-line design tools will access the Kernel directly. They need to know not only the value of the data but also the semantics of the data. For this purpose, the data have to be represented explicitly and not in an abstract form. A late-binding Kernel will not be able to provide this support. Therefore, an alternative solution, a combination of early and late binding, was investigated. The aim was to overcome the disadvantages of both approaches while keeping their respective advantages. Two key technologies were used to achieve this aim, the IS0 Standard Data Access Interface (SDAI) [6] and Objectstore database metaobject protocol [4].

Using the adopted strategy, the DES Kernel stores three types of data: (1) schema objects, (2) building objects, and (3) system objects. Their relationship is illustrated in Fig. 2.

Schema objects are conceptual definitions of building objects stored in the Kernel. Their data structure is defined by the SDAI dictionary schema. The IDM schema is the first schema to be stored in the Kernel database. It includes all the entity defini-

system objects

populated folder empt> foldr,

~_..__.___.__.____..------_-.--.-.--.-. building objects

Fig. 2. Data exchange kernel structure.

tions or data types of the COMBINE system, such as Room, Wall, Window, etc. In addition to the IDM schema, sub-schema, a subset of the IDM, for individual design tool functions is also stored. The schema data will be used to determine the data set to be exchanged between the DES Kernel and individual design tool functions.

A building model consists of a collection of objects the structure is of which is defined by the schema objects. These objects are stored in the form of folders. Each schema object defines a folder for that particular type of object, for example the schema object, Room, defines a folder for storing all room objects of a building model. Through the link between the building objects and schema objects, the DES can interrogate and manipulate not only the content of the data model in the Kernel but also the EXPRESS structure of the model.

The system objects are data about tools that operate on the building model in the COMBINE system, including Design Tool, Design Tool Function and Locker. Objects representing the design tools are created during the initialisation of the DES Kernel. Each design tool comprises a set of design tool functions which represent the tasks a specific tool will perform. The same software tool can be used for different functions. For example the same energy simulation package could be used to evaluate over- heating risk or insulation requirements. Each design tool function has a data input requirement, defined by its input schema and a data output defined by its output schema. The Locker object is required to efficiently manage the exchange of data between the Kernel and design tools. Its purpose is to store the information about which entity types have been checked out of the database for modification and to prevent two design tool functions from changing the same data concurrently.

4. Integration with CAD

To gain acceptance by the design professionals in practice the COMBINE IBDS needs to be integrated with the main stream CAD packages. Efforts were made for such an integration with AutoCAD and microstation. The aim was not to develop a new full-blown intelligent CAD, which was beyond the


scope of COMBINE, but to bridge the gap between the current graphic-based CAD applications and the product model based COMBINE IBDS by establish- ing a data interaction link. This approach has the following benefits: * It allows the designers to retain their familiar

ways of using the existing CAD packages during the design stages.

- It enables the designer to migrate design data from CAD drawings to a building model, in compliance with the COMBINE IDM schema, and populate the data exchange kernel.

- 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. Since AutoCAD and Microstation have quite dif-

ferent operating environments and programming lan- guage support, separate integration strategies were needed for them. To achieve development efficiency, a layering approach 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 is a communication interface layer (Fig. 3).

The first layer is the Objectstore database which provides application schema initialisation, and ser- vices 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 COM- BINE context. The implementation of this layer re-

COMBINE Application Program Interface

IDM objects behaviour (e.g. space volume)

IDM objects creation, deletion, and navigation

Objectstore database layer

Fig. 3. Integration with CAD.

quires the interpretation of the IDM schema as well as object composition knowledge. The third layer is IDM object geometrical and topological behaviours. Typical examples are the transformation of co- ordinates, calculating surface areas or space vol- umes. These three layers together define the functions needed by the CAD tools for the IDM objects.

Both AutoCAD and Objectstore support the C + + programming environment, the interaction between the AutoCAD tool and the DES Kernel can be achieved by sharing C + + objects in computer memory. However, the Microstation MDL programming environment is only C compliant, the interaction between Microstation and the Kernel at binary level is not possible. Therefore, a layer of COM- BINE Application Program Interface was introduced. This layer defines the standard protocols through which the CAD integration functions can be called. With this layer, the two CAD tools are able to use their own way of communicating with the DES Kernel. The AutoCAD tool adopted C + + static libraries and the Microstation tool used windows socket as a means of inter-process communication.

The COMBINE CAD tools expand the data semantics from merely graphic objects in the commer- cial CAD packages to COMBINE IDM objects. The CAD tools work with the semantic richer data structure and store data directly in the Data Exchange Kernel. The native AutoCAD and Microstation functions are used only as a graphical user interface. For example, when a designer wants to create a “Room” object, he or she may draw a rectangle using Auto- CAD command. In the background, a series of objects are initialised in the Kernel database. They include the room object itself, walls, ceiling and floor objects that bound the room, and geometrical and topological objects representing their shapes, etc. The object creation rules are defined in the second layer of the system configuration (Fig. 3). After all the objects are created, a link is established between the rectangle object in AutoCAD and the Room object in the database.

5. Interaction with off-line design tools

Off-line design tools operate independently from the Kernel. They can be separate programs on the

152 M. Sun, S.R. L.ockley/Automation in Construction 6 (1997) 147-155

same computer, or they might reside on different computers, even at different locations. The data exchange between the Kernel and design tools is through an intermediary medium, the STEP [7] file. When a design tool requests data from the Kernel, it receives the data in the form of a STEP file, and when the design tool submits data to the Kernel it does this also through a STEP file. The off-line data exchange is done at a schema level not object level, it is guided by the comparison of a design tool sub-schema and the IDM schema. For example, if a “Room” entity is a part of a design tool function’s input schema, it will get all rooms in a building from the Kernel instead of a particular room.

Data exchange between the Kernel and off-line DTs involves a bi-directional data mapping between an integrated global view of a building model in the Kernel and a partial view required by the design tool. The process of importing data from the design tool into a Kernel database is referred to as “meshing”, because it merges a partial model into a richer model. However, the process of exporting data from a Kernel database to a design tool file 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 (Fig. 4).

The “stripping” process to extract data for a design tool function is performed in five phases: 1. Retrieving the Design Tool Function schema data.

The object representing the targeted design tool

function and its input schema are retrieved from the Kernel. Through the schema, the DES identi- fies the entity definitions that are required for the data exchange and any constraints to apply. Getting the instances. Having identified the name of all the entity definitions to be extracted, the next step is to locate the building model in the Kernel and to find all objects to be exported by scanning the populated folders. Validation. Prior to processing the objects, a validation check can be executed to ascertain that they comply with the specified design tool sub- schema, for example, checking that all non-op- tional attributes do have a value. Creating a STEP file model. Once all objects and their attributes are identified and validated, a STEP syntax tree is created in the kernel. Writing out the STEP file. The last action is to create a STEP physical file to be passed on to the off-line design tool. The “meshing” process also consists of five

Reading the STEP file. A parser has been written which takes the STEP file and creates a persistent abstract representation of the file inside the Ker- nel. During this process the content of the file is syntactically validated. Identifying the schema. As with the stripping process the targeted design tool function is identified and its schema definition is retrieved. This

-

meshing

\

Fig. 4. Data exchange between kernel and off-line design tools.

M. Sun, S.R. Lockley/Automtion in Construction 6 (19971 147-155 153

3.

4.

schema definition is used to validate that every instance in the STEP file complies with the design tool function schema. Accessing the instances in the Kernel. A conven- tion was made that every object which already exists in the Kernel has a unique positive integer number as its identifier, and new objects to be created have a negative identifier. The actual meshing operation is done in two passes. The first pass is to create the new objects and to identify the corresponding objects for the existing objects. The first pass does not modify the attribute values nor create the attribute values for the new objects. Merging the new object data into the Kernel. The second pass is to go through the all objects and check whether any attributes need to be modified or created.

5. Validation. Finally the resulting model is vali-

dated against the IDM schema constraints.

6. Concurrent control and change notification

In COMBINE, the Data Exchange Kernel is a shared resource accessed by multiple design tools, sometimes concurrently. This requires a control mechanism to manage the transaction in order to avoid violation of data integrity. Two approaches were considered for the concurrent control. The first was the in-built Objectstore facility of configurations

and transaction management, and the second was the EXPRESS sub-schema mechanism.

The Objectstore configuration facility allows a collection of objects to be grouped together. The criterion used to determine how objects should be grouped into configurations is whether or not they are part of the same “design component”. For example, a HVAC system in a building could be considered as a design component, comprising ducts, terminators, fans etc.

Unfortunately, this approach is orthogonal to the COMBINE approach. In the COMBINE IBDS, all data exchanges for design tools are based on sub- schema definitions of the data requirements. A design tool specifies the types of data it needs in its input schema not particular data instances. However, the Objectstore configuration mechanism defines the data to be exchange by instances not types. Consis-

tent with the COMBINE general approach, the concurrent control of the DES also adopted a method of comparing subschema. Two objectives of this control are: - To avoid more than one DTF writing to the same

data area at the same time. - To advise any DTF whose input data is changed

by other DTF’s data interaction. Considering the scenario of two DTFs accessing

the Data Exchange Kernel, Rl represents the input data set and Wl represents the output data set for the first DTF. The relationship between Rl and Wl is unimportant: they could be mutually exclusive, have a partial intersection, or one could contain the other. The data interaction is controlled by checking interactions between data sets of the first DTF and those of the second DTF represented by R2 and W2. For the purpose of concurrent control, the relationship between these data sets can be classified into four categories (Fig. 5).

(a> The data sets for the two DTFs are mutually exclusive. In this case, the data interactions for these tools have no impact on each other, and they can proceed without any constraint.

(b) There is an intersection between Wl and W2. It implies that these two DTFs could potentially write to the same data area. To avoid damage of data integrity in the Kernel, the second DTF is not allowed to start the data interaction until the first one

terminates its interaction. (c) An intersection exists between R2 and Wl. In

other words, the input data for the second DTF could be changed by the interaction of the first DTF. Both interactions are allowed to proceed. However, at the point when the first DTF writes data back to the Kernel, the second DTF will be notified about the

(h)

Fig. 5. Concurrent engineering control.

154 M. Sun, S.R. Lacklq/Automation in Construction 6 (I997) 147-155

changes. Higher level control would decide whether the second DTF needs to abandon its ongoing interaction and restarts.

(d) An intersection exists between Rl and W2. Both interactions are allowed to proceed. At the point when the second DTF writes data back to the Kernel, the first DTF is notified about the changes, and again higher level control would decide whether a re-calculation is needed for the first DTF.

7. Version and history management

In many existing database environments there is little support for maintaining history of changes beyond the scope of one working session. Typically the persistent data only holds the latest or current version of a design, Object-oriented database systems offer the possibility of maintaining multiple states that a model has been through. Specifically, the Objectstore database was chosen for its strength in this respect.

Objectstore handles a design version and history tree through the use of “configuration” and “workspace” [4]. A configuration serves to group together objects that are to be treated as a unit for the purpose of versioning. Workspaces provide a context for several design tools to share different views of the same data. In the absence of design state modelling, the whole integrated building model is treated as a single configuration in the DES. During the evolution of the design, each data change submitted by a DTF will create a new version of the model which is stamped with a creation time and an identi- fication of the responsible DTF. Objectstore makes this an efficient process by only storing the changes that are made to each version. At any time, the version tree can be walked and effectively rolled

back to any previous state. Using this mechanism two or more tools can

check out or branch the building model, work on different versions of the model independently before checking the final results back into the current version. Whilst a version is checked out it is private to the particular design tool and other tools continue to see the agreed current version. After the check in of a modified version all shared views are updated.

8. Conclusions

The Data Exchange System as described in this paper was tested in the context of the COMBINE integrated building design system prototype. It demonstrated that the integrated CAD tools can ini- tialise a building model in accordance with the Inte- grated Data Model, and data representing a range of different views were extracted for design tool functions that need to be performed during the design process. The output data produced by these tools in the form of STEP file were imported and meshed into the kernel database. In addition, the DES showed the ability of data transaction management, object versioning and support for concurrent engineering.

A number of conclusions can be drawn based on the COMBINE project experiences, especially the development of the Data Exchange System [8]. - A data exchange system can be built that is

generic enough to handle any conceptual data model, but this by no means denies the crucial importance of a generally accepted data model for a design system.

- With an Integrated Data Model, it is possible to construct and populate a complex building model capable of meeting the needs of a range of different design tool functions.

* Existing CAD engines can be configured to operate with the high level semantics of a product model. However it would be more desirable to replace the simplistic representations in the CAD databases with building specific schemata, such as the IDM. The latest Industry Alliance for Interoperability initiative and the Autodesk’s plan to develop Industry Foundation Classes are set to achieve this goal [9].

- Object database technology is mature enough to be applied to building design systems.

- ISO-STEP and EXPRESS are viable tools for data modelling and exchange.

Acknowledgements

The work presented in this paper is part of the COMBINE project which has been funded by the EU Commission as part of the JOULE program. The authors would like to acknowledge contributions by


Department of Civil Engineering, Technical Univer- sity of Delft and TNO-BBI Building and Construc- tion Research of the Netherlands.

References

[I] G. Augenbroe, An overview of the COMBINE project, in:

R.J. Scherer (Ed.), Product and Process Modelling in the

Building Industry, A.A. Balkema, Rotterdam, 1995, pp. 547-

554. [2] A.M. Dubois, J. Flynn, M.H.G. Verhoef, et al., Conceptual

modelling approaches in the COMBINE project, in: R.J.

Scherer (Ed.), Product and Process Modelling in the Building

Industry, A.A. Balkema, Rotterdam, 1995, pp. 555-565.

[3] G. Augenbroe, Design systems in a CIM context, in: P.

Brandon, M. Betts (Eds.), Integrated Construction Informa-

tion, E and FN Sport, 1995, pp. 194-212.

[4] Object Design, ObjectStore release 3.0, User Guide, 1994.

[5] IS0 10303-l 1, Industrial Automation Systems-Product Data

Representation and Exchange, Part 11: The EXPRESS Lan-

guage Reference Manual, 1992.

[6] IS0 10303-22, Industrial Automation Systems-Product Data

Representation and Exchange, Part 22: Standard Data Access

Interface Specification (Draft), IS0 TC 184/SC4, 1993.

[7] IS0 10303-21, Industrial Automation Systems-Product Data

Representation and Exchange, Part 2 1: Clear Text Encoding of

the Exchange Structure, IS0 TC 184/SC4, 1993.

[8] S.R. Lockely, M. Sun. The Development of the Data Ex-

change System, COMBINE II-Task 3 Final Report, Depart-

ment of Architecture, University of Newcastle upon Tyne,

1995.

[9] S. Kinghom, C. Findlay, I. Carolan, Towards a new architec-

ture: setting standards in the AEC industry, CAD User 9 (1)

(1996) 20-22.

Documents

Data exchange system for an integrated building design system