intelligent models for collaborative construction engineering

Computer-Aided Civil and Infrastructure Engineering13 (1998) 151–161

Intelligent Models for CollaborativeConstruction Engineering

Yacine Rezgui,∗ Alex Brown, Grahame Cooper,

Information Technology Institute, University of Salford, Manchester M5 4WT, United Kingdom

Peter Brandon

Reseach & Graduate College, University of Salford, Manchester M5 4WT, United Kingdom

&

Martin Betts

Department of Surveying, University of Salford, Manchester M5 4WT, United Kingdom

Abstract: Many critical issues still need to be tackled prop-erly in order to manage concurrent engineering projects ef-fectively. These issues include versioning, notification, andpropagation, all of which need to be addressed throughoutthe construction project lifecycle. To this end, the COMMITproject strives to achieve an improved level of support forthe versioning of project information at both the conceptual(schema evolution) and the instance levels. Versioning, notifi-cation, and propagation are addressed through the CIMM(ageneric and context-independent information managementmodel for supporting collaborative construction projects)and are described in this paper. The main concepts of theconstruction-oriented COMMIT Canonical Model(CCM),specialized from the CIMM, are also presented, followed by adescription of the first prototype implementation of the CIMMtackling information versioning.This research is ongoing andsupported by a well-established U.K. steering group.

∗ To whom correspondence should be addressed.

1 INTRODUCTION

Industrial processes are increasingly characterized nowadaysby the intensive use of information technology. When com-puter-based applications were first developed, they were in-tended to support individual users working on distinct projects.Today, the complexity of industrial processes inevitably in-volves a closer interaction between a project’s engineers.While computer-aided manufacturing is gaining popularityin several industrial sectors—because of the integration ofdesign and construction activities—the construction indus-try is still striving to achieve a reasonable level of designprocess integration. It is commonly agreed that integration isthe key issue that architecture, engineering, and constructionprojects will have to address in order to meet the ever-growingdemands of society.3,4

Construction projects involve virtual teams being broughttogether for projects and broken apart on completion. Thechanges that actors make to the information describing aproject throughout its life cycle need to be recorded alongwith the intent behind them. Hence several issues need to beaddressed in order to support construction projects

© 1998Computer-Aided Civil and Infrastructure Engineering. Published by Blackwell Publishers, 350 Main Street, Malden, MA 02148, USA,and 108 Cowley Road, Oxford OX4 1JF, UK.

152 Yacine Rezgui, Alex Brown, Grahame Cooper, Peter Brandon, & Martin Betts

effectively; these include

• Versioning. This is a mechanism used to keep track ofall the states in which an object has existed, including itscurrent state. The primary reasons for providing a struc-tured environment in which changes made to objects arerecorded are (1) to provide the client with a completeproject history and (2) to facilitate backtracking. In ad-dition, because actors often refer to previous versions ofobjects, a structured historical versioning environment re-duces ambiguity by standardizing version numbers andallowing the examination of previous versions of objects.The design process involves the proposition of new, possi-bly alternate versions of construction project objects. Anenvironment in which the concept of proposed versionsis supported and in which proposed versions are distin-guished from historical versions would improve construc-tion project communication.• Notification. This is the process by which actors are kept

informed by any change introduced to the project infor-mation base, provided that it is relevant to them. For in-stance, the civil engineer should be informed by most of theamendments made by the architect to the project (addingor removing walls, increasing the height of a storey, etc.).• Propagation. This involves changing the properties of a

set of target objects because of a change introduced to asource object. For instance, we may need to have the widthof a beam increased whenever the width of the column sup-porting that beam is increased. The aim, in this example, isto have an equal width for both the column and the beam.The automation of this change would be termed (in thecontext of this paper)propagation.

In most existing approaches to integration, versioning fre-quently has been addressed on the implementation side1,6

through computer programming or by making use of theversioning capabilities of some proprietary software prod-ucts, e.g. Object Store (an object-oriented database manage-ment system developed by Object Design, Inc., that providessupport for object versioning). A model-based solution toversioning7 (where versions are conceptualized and objec-tified through an information model that is inherent to theapplication conceptual model, as described in Sec. 3) has sev-eral advantages. First, models are independent of any partic-ular implementation and therefore are more likely to survivethe rapid evolution of information technology. In addition,conceptualizing versions is beneficial in representing objectinterrelationships throughout the project life cycle, as will bedemonstrated in this paper. Finally, any model-based repre-sentation of versions is exploitable by other information- orknowledge-based systems.

Addressing the versioning issue constitutes one fundamen-tal aim of the U.K. EPSRC-funded COMMIT project, whicharose from work carried out on the initial ICON project.2 Thispaper, based on COMMIT research, gives a comprehensive

description of how a project’s history can be recorded bymeans of an information model that supports intelligent ver-sioned objects. The research is ongoing and supported by awell-established steering group comprising regulation bod-ies, research institutions, and industrials.

2 VERSIONING, PROPAGATION, ANDNOTIFICATION ISSUES

An object has a state, a unique identity, and a behavior.The collection of the object’s properties defines its struc-ture. The state of an object is described by both its under-lying semantics—its structure—and the set of its properties’values. Any change made to an object’s property implies achange in the state of that object. Versioning, as mentionedearlier, is a mechanism used to keep track of all the statesin which an object has existed, including its current state.An object type describes a set of objects having a commonstructure and behavior. It also defines the constraints char-acterizing the object’s states. Any serious attempt to supportversioning must address two distinct levels: the conceptualmodel level (which assumes that versions are created when-ever the structure of an object evolves or changes) and theinstance level (which assumes that versions are created when-ever an object’s properties are amended). The first versioningmechanism supports the dynamic evolution of the conceptualschema. Dynamic schema evolution has two distinct useswhen modeling construction projects. The first is to describean object type’s structure throughout its life cycle, wherebyan object type is allowed to exist in more than one version,each version containing only those attributes relevant to agiven design context or project stage. The second use is to al-low designers to modify, for project-specific design reasons,the structure of an existing object type (by adding, deleting,or modifying an object type property). The instances of anobject type might thus be generated from distinct versions ofa common object type (Fig. 1). We consider dynamic con-ceptual schema evolution to be a prerequisite for successfulcollaborative engineering.11

An object type or an object might exist as an aggregationof a set of object types or objects, respectively. The ques-tion one might ask is whether we need to create new objecttype versions or object versions whenever a new version ofthe object type aggregate or object aggregate is created. Themechanism that involves such changes is termedpropagation.We can have three types of propagation (Fig. 2): a top-downpropagation (this implies that new versions of the object’scomponents are created whenever the object aggregate is up-dated), a bottom-up propagation (a modification of an object’scomponent needs to be propagated to the object aggregate),and mixed propagation (which takes place between objectsirrespective of their relationships). The propagation issue canbe addressed by declaring a given object to be “sensitive,” in

Intelligent Models for Collaborative Construction Engineering 153

Fig. 1.Object types and versioning.

Fig. 2.Propagation mechanism.

which case any change made to it needs to be propagated ac-cording to a top-down, bottom-up, or mixed propagation.12

However, we consider that in certain design contexts, a sen-sitive object may require that specific conditions are satisfiedbefore propagation can take place. For example, the changeof a wall’s load-bearing layer width by the structural engi-neer should, in some cases, update the total width of thewall. In other cases, the architect’s approval might be re-quired first. In many object-oriented environments, for ex-ample, C++, aggregation is implemented in the same wayas other relationships such as reference. Similarly, we con-sider that the propagation of versions should be treated in auniform way, whether this propagation was necessitated bythe existence of aggregation relationships or the existence ofdependency relationships. Hence propagation could be eitherhandled interactively, case by case, or automated by the useof knowledge-based system technology. It should be decided,for each update, whether propagation is required, which ob-jects need to be updated, and which methods to invoke orrules to apply.

Versioning and propagation are the consequence of actors’interactions with the project information base. These actorsoften collaborate on well-defined tasks resulting from a top-down hierarchical decomposition of the design process. Each

task involves a number of transactions through which the ac-tors interact extensively. A transaction can be subdivided intosmaller nested transactions and often involves iteration andexperimentation. Each transaction may lead to the creation ofnew objects or result in changes to the project’s informationbase. Design objects therefore go through several transientstages before a stable state is reached. If large transactionsare discretized into smaller and less important units, changescan be localized, and undesirable design decisions can be un-done more easily. Thus nested transactions provide smallerunits for transaction commits, recovery, and rollback1 andtherefore are more adapted for collaborative engineering.

3 THE PROPOSED COMMIT INFORMATIONMANAGEMENT MODEL

The issues mentioned before (including versioning, propa-gation, and notification) are addressed through a conceptualframework consisting of four levels of abstraction and func-tionality governed by the COMMIT Information Manage-ment Model (CIMM). A comprehensive description of theCOMMIT methodology and the COMMIT conceptual ap-proach is given in ref. 10. A primary aim of the CIMM is tocapture, through the use of versioning, the process by whichthe project actors make decisions (what objects are concernedwith the decision, who is initiating the decision, how is theinformation being used and processed, and what will the im-pact of the decision be on the information base?). Capturingthis process will provide a basis for sound recording of deci-sions made by actors and the intent behind them during theconstruction project lifecycle.

3.1 The CIMM core concepts

The two fundamental entities of the CIMM are theObject-TypeandObjectconcepts. TheObjectTypeis defined as theclass from which objects sharing the same structure and be-havior can be instantiated. We argue that any artifact from theuniverse of discourse that can be conceptualized is, in fact,an object, irrespective of its nature (class or an instance of aclass). AnObjectTypeis therefore defined as a subtype of theObjectconcept even though the latter actually represents aninstance of theObjectType(Fig. 3). The main advantage ofthis approach is that all issues surrounding collaborative engi-neering, including versioning, notification, and propagation,can be addressed at the object level and then inherited by theobject type.ObjectTypesandObjectstherefore can both haveversions, and support for schema evolution is automatic.Ob-jectsare instantiated from particularObjectTypes’versions.Moreover, eachObjectwill have an initialObjectType Ver-sion (representing a version of a specificObjectType) fromwhich it is created.


Fig. 3. Objects and versions. Rectangles represent object typesthat describe concepts. Lines joining object types represent

bidirectional relationships. Each relationship has a cardinality ofone (represented by one line) or many (represented by crows foot).Optionality is represented by a small circle meaning “sometimes”or by a single line meaning “always.” Small box denotes completepartition, which is a type partition that expresses a full list of itspartitioned subtypes. When a line is added inside, the partition

expresses a partial list of subtypes.

3.2 The CIMM concepts for versioning and decision sup-port

The CIMM concepts that facilitate the modeling of versionsand the recording of intent are illustrated in Fig. 4. In ad-dition to the advantages of a model-based (as opposed to animplementation-based) approach to versioning already given,version modeling also complements a record of intent. Asmentioned before, anObjectTypecan exist in one or moreversions (in order to support the evolution of a conceptualmodel throughout the building life cycle). The structure andbehavior of an object type therefore can be specified dynam-ically. In this context, the object instances instantiated froma common object type might have been generated from dif-ferent states of that object type. A new version of an objectis automatically created whenever a new version of the ob-ject type of that object is created. AnObjecthas one or more

Fig. 4.The creation and management of versions in the CIMM.

Object Versions, one of which is the current version. Objectversions, both current and noncurrent, influence aDecision—a human conclusion that is recorded by aStatementofIntentand affects one or more objectOperations. These operations,in turn, generate one or more new object versions. The in-tent behind project decisions is thereby recorded not onlyexplicitly by the statement of intent but also implicitly bythe relationships between various object versions and a deci-sion. In the same way, object type versions, both current andnoncurrent, influence a decision that triggers one or moreobject type operations. These operations, in turn, generateone or more new object versions. It should be emphasizedthat at least one version of an object type exists that holds itsstructural and behavioral information.

Decisions can be linked and represented in the form of agraph (Fig. 5). A decision can influence a set of other deci-sions while being itself influenced by a decision or a set ofdecisions. As indicated in the example given in Fig. 5, thedecision to increase the width of all the beams of the secondstory of a fictitious building (D3) is influenced by both thedecisions of moving the canteen of that building from thefirst to the third story (D1) and the decision of making thatcanteen public (D2). D3, in turn, influences the decision ofincreasing the dimension of the columns of story 2 (D4), thedimension of the walls of story 2 (D5), and the dimension ofall the foundations (D6).

3.3 The CIMM concepts for change notification and prop-agation

The model presented in Fig. 6 allows the complex chainsof modifications and amendments that typify constructionprojects to be recorded. All changes are initiated by actorsthrough their defined roles. Notification is the process bywhich amendments made to objects are notified to the vari-ous roles concerned with that object. The spread of mailingsoftware, used through local- and wide-area networks, means


Fig. 5.The concept of a decision tree.

that the CIMM not only can represent this notification butalso to a large extent automate it. Many individuals will notbe used to working in an integrated construction environmentin which project information changes at a rapid pace. A noti-fication mechanism is therefore essential for keeping actorsaware of project changes and also supports the automation ofother information management processes such as approval.Figure 6 describes the notification process that involves rolesand objects at the conceptual and instance levels. A role rep-resents either a project role (inception, design, construction,and maintenance) or an analytical role (knowledge expertwho specifies and makes changes to the conceptual modelused during the project’s lifecycle). We have decided to con-ceptualize the notification process through the concept ofNo-tificationObject. This holds many details, including the dateand time on which the notification occurred, along with theimportance and priority of the notification.

Object types are related to a default set of roles that typi-cally will need to be notified in case of any modification tothe instances of that type. This relationship is the same forobjects, from which object types inherit the notification capa-bilities. Objects take possession of this set of roles, but sincethese roles can vary from one instance to another, objectshave their own specific set of roles to notify. The CIMM alsosupports the specification of notification lists at the versionlevel in order to accommodate the complex interaction ofroles and proposed information changes in construction ac-tivities such as design. Therefore, a modification to an objectversion notifies a set of roles, which sometimes may differfrom those attached to the object and defined as default withinthe object type. Figure 7 (right side of the figure) illustratesthe notification process as applied to object versions. ObjectA has a specific set of roles to notify in case of modification:R1, R2, and R4, which also apply to the initial version A0. A0

is then modified creating version A1; roles R1, R2, and R4are notified. The project manager then decides that versionsof A derived from A1 require the notification of role R3 butnot R2. A modification made to version A1 creates versionA2 and notifies roles R1, R3, and R4.

In a similar manner to notification, propagation is con-ceptualized through the conceptChangePropagationObject.Propagation involves the CIMM making inferences on the ba-sis of project information. As described in Sec. 3, propagationcan be used to support those version changes necessitated byaggregation relationships. It is modeled in a similar way tonotification; an object type, object, and object version mayall have a unique set of objects to which a modification ispropagated. In an expert system based on production rules,such a set would constitute an individual rule. The relation-ships needed to support propagation are illustrated in Fig. 6.The CIMM also includes theProjectEventconcept, whichprovides a systematic way of retrieving all instance versionscreated during the construction project life cycle. As manyversions are created as a result of version propagation, singleupdates of theProjectEventcan represent project changesinvolving the creation of several new versions of various in-stances. This is illustrated in Fig. 7 (left side of the figure),where a new version A3 of object instance A is created andthe change propagated to instances B and C, thereby cre-ating new versions B2 and C3, respectively. All three newversions, A3, B2, and C3, are represented by a single updateof theProjectEvent.

The concepts of the COMMIT Canonical Model (CCM)are specialized from the CIMM. Therefore, they inherit allthe versioning and change notification capabilities describedabove.


Fig. 6.Notification and propagation in the CIMM.

Fig. 7.Notification and propagation.

4 THE COMMIT SAMPLE CANONICAL MODEL

The CCM is an information model that contains abstrac-tions that have been agreed on as being generally useful.The entities in the CCM can be seen as a language, holdingnonambiguous semantics, that is used to communicate con-struction information and data between the actors involved inthe project life cycle. The CMM describes information at alllevels of detail, from very abstract concepts, such asCCM-ContainerandCCMContentsobjects (described below), toconcepts close to those used in actors’ daily practices.

A project’s life cycle is structured into phases—termedconstruction stages—involving a set of activities. The con-current engineering nature of today’s processes implies thatseveral stages might be run at the same time (e.g., the con-struction stage might start while some design issues are stillbeing addressed by the project engineering companies). Sev-eral skills and specialities are involved in each stage. They

are described through the concept ofCCMRole. This conceptdesignates the mission of an actor along with the responsi-bility attached to it. This mission is in turn implemented by aset of activities. ACCMDisciplinedesignates a grouping ofCCMRoles(Fig. 8).

A CCMRoleis performed by one or many actors. It alsomay consist of an aggregation of otherCCMRoles. Exam-ples of CCMRolesinclude project management and archi-tectural design. EachCCMRolemay be implemented by oneor manyCCMActivities. EachCCMActivityis described, asindicated in Fig. 9, by aCCMCostobject (which holds all theactivity’s financial details), aCCMResourceobject (whichspecifies the resources—including services, materials, andequipment—used for the implementation of the activity), aCCMQualityStandardobject (which describes any industrystandards to which the activity must adhere), and aCCM-TimeFrameobject (which holds all the actual and plannedactivity’s temporal details). Because roles are defined in a


Fig. 8.The CCM context diagram.

Fig. 9.The concept of role.

recursive way—a role may consist of several other roles—theCCMQualityStandardcan describe industry standards towhich the activities of a given role must adhere. Activities aredescribed at different levels of decomposition of the project’sroles, including the highest level (which represents the qualityof the overall system). ACCMActivitycan be either an exe-cutable or an intellectual task; it sometimes can comprise bothtypes of tasks; e.g., the realization of a roof may require addi-tional engineering design from the contractor in accordancewith a specific implementation technology. Aworkpackageis therefore defined as a grouping of executable tasks that areto be implemented by a precise contractor.

A CCMProductis specialized into aCCMContainerOb-jectandCCMElementObject(Fig. 10). The concept ofCCM-Containerdesignates a box that serves as a shelter for peo-ple, goods, or equipment. It satisfies one or many functional,technical, and aesthetic purposes. ACCMContainerObjectis

made ofCCMElementObjects. Examples ofCCMContainer-Objectsinclude buildings, storys, and rooms. Examples ofCCMElementObjectsinclude walls, doors, and floors. EachCCMElementObjectbelongs to at least oneCCMSystemOb-ject (e.g., a load-bearing wall belongs to both the structuraland separation systems). TheCCMContainerObjectsare inrelation with each other viaCCMTransitionObjects. Exam-ples of these transitional objects include corridors, staircases,and lifts. EachCCMContainerObjectcontains aCCMCon-tentsObjectsuch as a space to which a set of requirementsis attached. The latter may be equipped with one or manyCCMElementObjects, including heating and cooling devices.Each product can be found inCCMProductLibraries, whichare structured in accordance with a preciseCCMClassifica-tionSystem.

Figure 11 describes theCCMContainerObjectconcept. ACCMBuildingComplexconsists of one or manyCCMBuild-


Fig. 10.The product concept.

Fig. 11.The container concept.

ings. EachCCMBuildingmay consist of one or manyCCM-BuildingUnits describing a functional grouping ofCCM-Rooms(e.g., a housing flat). ACCMBuildingconsists of oneor manyCCMStorys, which in turn consist of one or manyCCMRooms.

Figure 12 describes theCCMContentsObject. This canbe either aCCMSpaceObjector CCMZoneObject. A zone

consists of a set of spaces, and each space may belong tomore than one zone. EachCCMContentsObjecthas one ormany functions and may have one or many requirements (e.g.,thermal, lighting, aesthetic, or acoustical requirements). Thisway of addressing space and zone requirements—through theCCMRequirementObject—leads to a better choice of materi-als and equipment and therefore an improved project quality.


Fig. 12.The contents concept.

5 AN IMPLEMENTATION OF THEMODEL-BASED SOLUTION

5.1 Implementation technology

The aim of the CIMM prototype is to demonstrate informa-tion production and management in a concurrent multiactorenvironment. While information integration frequently hasbeen achieved through the use of relational or object-orientedclient/server databases, the use of a platform-independent dis-tributed object technology promises more flexible client/ser-ver systems. The COMMIT project therefore has chosen toimplement the CIMM as a set of CORBA (Common ObjectRequest Broker Architecture) compliant distributed compo-nents that make use of CORBA services. For details of theCORBA specification, the reader is referred to the OMGdocumentation.9

The backbone of the COMMIT integrated construction en-vironment is an ORB (Object Request Broker) that managesthe low-level interoperability between objects. The ORB alsoprovides the low-level CORBA services necessary for dis-tributed computing and provides transparency of platformand location. Objects participating in the distributed envi-ronment are specialized from CIMM objects, whether theyreside independently or in applications. The invocation ofmethods on objects in the computer-integrated constructionenvironment therefore can be tightly controlled. It might benecessary, for example, to check the right of a certain role toperform a given method.

The COMMIT project has chosen C++ for software de-velopment. It is the most widely used object-oriented lan-guage and, crucially, has a robust CORBA binding. The C++classes generated are augmented for use with the Object-Store object-oriented database and ORBIX (a CORBA im-plementation developed by Iona Technologies, Inc., that al-lows the distribution of objects in an ObjectStore database).

The end result is a set of distributed objects that implementthe CIMM and so provide CORBA-compliant informationmanagement services for computer-integrated constructionenvironments. The combination of ObjectStore and ORBIXprovides database and CORBA services that alleviate manyof the implementation problems (which are not addressedby the model-based CIMM) associated with integrated con-struction environments. These services include transactions(which prevent concurrency anomolies and provide rollback)and efficient object retrieval services. The CIMM user inter-face software is being developed in Visual C++ (C++ in-tegrated development environment developed by Microsoft)for the Windows NT and Windows 95 (both 32-bit operat-ing systems developed by Microsoft) platforms, again withOEW (Object Engineering and Workbench, a modeling en-vironment developed by Innovative Software, GmbH) beingused as a modeling tool.

5.2 The versioning support interface

The following scenario demonstrates the way in which theCIMM manages users’ access to object types, objects, andversions. It also shows how users are given access to inten-tion, propagation, and notification knowledge, which is madeexplicit. The scenario involves several project actors work-ing in conjunction on the design of a new large arts complexin the Manchester area, The Lowry Centre. Figure 13 showsthe panel from the prototype CIMM implementation an actorwould see if he or she wished to browse version information.An actor may be involved in more than one project; in thisexample, the actor has selectedThe Lowry Centreto work on.For large-scale construction projects, tools must be providedfor accessing information in a structured and discriminatoryway. In the VersCIM prototype, information may be browsedby Room, Story, andBuilding. In this example, the actor haschosen to browse object types in theMain Stageof theFirst


Fig. 13.Panel from VersCIM prototype.

Floor of theLyric Theatreand has selected theCurtain Wall.Each object type may exist in one or more versions; the ac-tor has chosen to look at versioncw1 (which is the secondversion of the object typeCurtain Wall) and is viewing thepanel showing the decision that led to the creation of thisversion (D3002). D3002 is the code given to the decisionthat led to the creation of version typecw1 of the object typeCurtain Wall. It also has a text attached to it that gives a de-tailed explanation of the decision. The panel gives also thecode of the decisions that its (D3002) existence influenced(D2004, D3459, andD3461). More detailed information onthese decisions is available through a panel (Goto Decision).The user also can view the graph of decision dependencies(Decision Tree). The structure and general information (suchas creation date, creator, etc.) of object types also may beviewed.

Each object type version may have zero or more objectinstances, which in turn may have one or more instance ver-sions. In this example, the actor views instancecw1.i6 (in-stance number 6 of object versioncw1 of the object typeCurtain Wall), instance versioncw1.i6.v25 (version number25 of instance i6 of object versioncw1of the object typeCur-tain Wall), and the instances that change to this instance willbe propagated to (99K). Instances whose value affects thisinstance (L99) also may be viewed and made the focus of theinstance panel (Go To). The general properties of instances,and the decisions behind their creation, may be viewed in the

same way as those of object types. A comprehensive descrip-tion of the prototype is given in ref. 5. Examples that illustratehow versioning, notification, and propagation would help anactor to make decisions are given in ref. 11.

6 CONCLUSION

This paper has presented a conceptual solution to the prob-lems involved in construction concurrent engineering, includ-ing versioning, notification, and propagation support through-out the construction project life cycle. The versioning issue isaddressed through the CIMM, an information managementmodel for supporting collaborative construction projects. Itdescribes the complex interactions that take place between theinformation units describing a building. Versioning addressesboth the conceptual model level, which promotes schemaevolution, and the instance level, where versions are createdwhenever an object’s property is amended. This problem isall the more complex in that object versions can be instanti-ated from different states or versions of their object type. Thepaper argues that an approach based on knowledge-basedsystem technology is the most appropriate for propagatinginformation changes and for representing dependencies be-tween objects in the information base. A notification mecha-nism is used to keep actors aware of project changes and alsosupports the automation of other information management


processes such as approval. Finally, a model-based solutionto the problem of versioning was presented, followed by adescription of the first VersCIM prototype implementation.

The approach presented differs from previous attempts toaddress the issues surrounding collaborative construction inthat it is strongly model based. The work presented in thispaper is ongoing; a prototype demonstrating all the ideasembodied in the CIMM is under development. In the longerterm, it is hoped that the COMMIT project will successfullydemonstrate the technical, economic, and sociologic benefitsthat would be gained by adopting an approach to informa-tion integration founded on an object-oriented informationmanagement model.

7 ACKNOWLEDGMENTS

We would like to thank the members of the steering commit-tee for their assistance for the whole duration of this researchproject. We also wish to acknowledge the financial supportof the EPSRC (U.K. Engineering and Physical Sciences Re-search Council).

REFERENCES

1. Ahmed, S., Sriram, D. & Logcher, R., Transaction-managementissues in collaborative engineering,ASCE Journal for Comput-ing in Civil Engineering, 6(1) (1992), 85–105.

2. Aouad, G., Betts, M., Brandon, P., Brown, F., Child, T., Cooper,G., Ford, S., Kirkham, J., Oxman, R., Sarshar, M. & Young, B.,

ICON Project: Final Report, University of Salford, Manchester,England, 1994.

3. Bjork, B-C., Requirements and Information Structures forBuilding Product Data Models, VT T Publication No. 245, Es-poo, Finland, 1995.

4. Brandon, P. & Betts, M.,Integrated Construction Information,E&FN, Spon, London, England, 1995.

5. Brown, A., Rezgui, Y., Cooper, G., Yip, J. & Brandon, P., Pro-moting computer integrated construction through the use ofdistributed technology,Itcon Journal1 (1996).

6. Katz, R., Toward a unified framework for version modeling inengineering databases,ACM Computing Surveys22(4) (1990),375–408.

7. Law, D. & Krishnamurthy, R., A configuration and version man-agement model for collaborative design, inInformation Rep-resentation and Delivery in Civil and Structural EngineeringDesign, Civil-Comp Press, Edinburgh, 1996, pp. 7–14.

8. MOB, Modeles Objet Batiment: Appel d’offres du Plan Con-struction et Architecture, Programme Communication/Con-struction, Paris, France, 1994.

9. OMG,The Common Object Request Broker: Architecture andSpecification, Object Management Group, 1995.

10. Rezgui, Y., Brown, A., Cooper, G., Aouad, G., Kirkham, J. &Brandon, P., An integrated framework for evolving constructionmodels,International Journal in Construction IT4 (1) (1996),47–60.

11. Rezgui, Y., Brown, A., Cooper, G., Yip, J., Brandon, P. &Kirkham, J., An information management model for concur-rent engineering,Automation in Construction(in press).

12. Talens, G., Oussalah, C. & Colina, M. F., Versions of simpleand composite objects, inProceedings of the19th VLDB Con-ference, R. Agrawal, S. Baker, D. Bell, eds., Dublin, Ireland,1993.

intelligent models for collaborative construction engineering

Documents