Information modelling for case-based construction planning of highway bridge projects

Information modelling for case-based construction planning of highwaybridge projects

J.H.M. Tah* , V. Carr, R. Howes

Project Systems Engineering Research Unit, School of Construction, South Bank University, Wandsworth Road, London SW 8 2JZ, UK

Received 1 December 1997; accepted 20 November 1998

Abstract

In practice, construction planning and control draws on large-scale project and corporate data repositories, which are often unstructured.This article argues that the development of a large-scale data repository should be the precursor to any case-based reasoning systemdevelopment. The article presents a large number of conceptual object models, which were developed to identify the attributes and relation-ships between product and planning information comprehensively, using bridges as a representative product. The models were used todevelop a large information repository implemented in a database management system to facilitate real world project information collation,organisation, and management to reflect the large-scale nature of construction projects in practice. The database acts as a source of cases andsub-cases that are retrieved and mapped into a case-base. These cases are considered individually for indexing, matching, retrieval, andvalidation purposes, facilitating the re-use of parts of multiple cases to construct new project plans. A prototype software model, CBRidgePlanner, which was developed and tested with real world project cases to demonstrate the approach is presented.q 1999 Elsevier ScienceLtd. All rights reserved.

Keywords:Construction planning and control; Bridges; Case-based reasoning; Object-orientated modeling; Project modelling; Database management

1. Introduction

The work presented in this article was developed againstthe background that previous research in the area of decisionsupport for project planning and control utilising expertsystems techniques have failed to make an impact in theconstruction industry. This was attributed to restrictionswith rule-based reasoning concerning knowledge acquisi-tion, rule-based knowledge representation, memory, learn-ing, and robustness [1]. In practice, construction plannersuse knowledge gained from previous plans to make deci-sions and to produce new plans. Once a project is completeall information relating to it is routinely archived, and even-tually destroyed after a set period of time. This appears to bea waste of valuable experience and hard data. Whilst it islikely that those involved with a project will rememberinformation relating to it, this memory will fade withtime. It is also possible that those personnel may leave thecompany taking the knowledge with them. It is acknowl-edged that many construction projects are unique, howeverthe methods and procedures used within them are usuallynot. This means that the information used for one project

may well be of use for another similar project. The lack of asystematic approach to storing past plans and problems thatwere encountered together with the solutions that were usedto overcome these problems means that plans have to beproduced from scratch every time a new project is to beplanned.

The purpose of the work presented in this article was toinvestigate the potential offered by a case-based reasoning(CBR) approach to address this problem. CBR is a techni-que of solving new problems by adapting solutions that wereused to solve previous ones [2]. CBR differs markedly fromother types of reasoning and problem-solving techniquesand is to some extent a direct consequence of the problemsof other techniques. The CBR process typically involvesmatching a new problem against previously encounteredcases stored in a case-base, and one or more similar casesare retrieved. One of the matching cases is then reused andtested for success. If the retrieved case is not a close matchthe solution is revised producing a new case that can beretained. In practice, construction planning and controldraws on large-scale project and corporate data repositories,which are often unstructured. Therefore, the work presentedin this article, centres on information modelling and repre-sentation for the development of a common data repositoryto support the CBR system development.

Advances in Engineering Software 30 (1999) 495–509

0965-9978/99/$ - see front matterq 1999 Elsevier Science Ltd. All rights reserved.PII: S0965-9978(98)00128-8

* Corresponding author.E-mail address:[email protected] (J.H.M. Tah)

The article presents conceptual object models, whichwere developed to identify the attributes and relationshipsbetween product and planning information comprehen-sively, using bridges as a representative product. Themodels were used to develop a large information repositoryimplemented in a database management system to facilitatereal world project information collation, organisation, andmanagement to reflect the large-scale nature of constructionprojects in practice. The database acts as an initial source ofinformation to feed a case-base of cases and sub-cases.These cases and sub-cases are considered individually forindexing, matching, retrieval, and validation purposes, facil-itating the re-use of parts of multiple cases to construct anew project plan. A prototype software implementation,CBRidge Planner, which was developed and tested withreal world project cases to demonstrate the approach ispresented.

2. Related work

CBR is currently a very active research area in the Arti-ficial Intelligence (AI) research community as exemplifiedin the comprehensive review by Watson and Marir [3]. Theannotated bibliography by Marir and Watson [4] indicatesthat a considerable number of prototype applications arebeing developed in areas including: knowledge acquisitionand refinement, legal reasoning, failure recovery, diagnosis,arbitration, design, general planning, help desks, teachingand learning. The areas of case-based planning and designare relevant to construction planning.

In AI a plan is a specific sequence of steps or actions withthe aim of achieving a goal. Case-based planning systemsre-use past sequences of actions from past plans to constructnew ones [5]. Systems like Julia [6], Prodigy/Analogy [7],and CAPlan/CBC [8] decompose the goal into smaller sub-goals, enabling plan composition by smaller sub-plans. Thisleads to a hierarchical representation of plan cases. The caserepresentation is similar to a tree where each node is a goaland the siblings are sub-goals, and the leaf nodes are theactions of the plan. Each goal or action depends on othergoals.

The construction domain is a growing area for applica-tions of CBR. Case-based design is currently the largestresearch field. Examples include architectural design[9,10], office design [11,12], integrated design and construc-tion [13], building design [14,15], industrial building design[16], building envelope design [17], and structural design[18,19]. These systems use various forms of representationschema including: attribute-value pairs grouped into sub-systems and to form hierarchies, both in case memory orga-nisation and indexing; 2-D and 3-D images; video clips;photographic or video still images; and textural descriptionsof various aspects of the case. Non-design CBR researchprojects include building regulation interpretation [20],repair and refurbishment of buildings [21], strategic cost

estimating for building refurbishment [22], contractorprequalification [23], housing renovation grant assessment[24], and materials selection [25]. Within the area of bridgedesign, Moore and Lehane [26] detail a system which allowsthe design data for small and medium-sized bridges to bestored in a case-base for future retrieval. It concentratespurely on the design aspects of the bridges and is primarilydesigned as a decision support tool as no adaptation featuresare implemented.

Within the planning domain, Kawooya and Aouad [27]discuss the development of an Case-Based IntegratedConstruction PLANner (CBI-CONPLAN) for use withinthe Open System for CONstruction project. CBI-CONPLAN is a system which stores information about abuilding’s design and its construction plan as a single case.Both the design and planning aspects of retrieved cases canbe modified to form new cases, though currently the deci-sion as to whether a generated plan requires further modifi-cation is made by a planning expert (future extensions to thesystem hope to overcome this). Additionally, Tommeleinand Dzeng [28] present CasePlan, a case-based reasonerthat automates the generation of construction schedulesfor power plant boiler erection. This uses a generic productmodel to establish the basis for comparing projects with oneanother, and is achieved using a model to represent aproject’s design and relating it to the construction schedule.The system uses planning and scheduling stages before anew case can be archived for re-use.

The common characteristic of all reviewed prototypesindicated that cases are grouped into sub-systems andform hierarchies, both in case memory organisation andindexing. Although, the basic representation is simple inthe form of groupings of attribute-value pairs, the case hier-archies build a more complex organisation. This facilitatesthe handling of real world problems, providing a naturalindexing schema for the retrieval of case information.

It is evident from the literature that CBR technology hasreached a state of maturity as a practical solution to rela-tively small-scale problems in the construction domain. Themajor focus was on knowledge engineering, with emphasison the cases and the indexing structure that organises thosecases for a specific application. However, tailoring a caserepresentation to the requirements of a single application isnot feasible in large-scale applications that supportconstruction industry activity. The reality is that these appli-cations draw on large-scale data repositories. Therefore, amore practical approach is to use CBR as a technique forexploiting existing databases. Brown et al. [29] argue thatCBR applications should be constructed on top of a singlelarge-scale data repository, where each CBR application istailored to a specific purpose to which the data can be put. Inthis approach, the cases within an application are virtualviews of the underlying data. The implication is that thedevelopment of a data repository should be the precursorto any CBR development. This involves the development ofa conceptual data model that represents details of the

J.H.M. Tah et al. / Advances in Engineering Software 30 (1999) 495–509496

information to be stored in the repository. The informationmodels developed in this work are presented later.

3. Case acquistion

Semi-structured interviews were conducted with selectedchief planners and project managers aimed at identifying thefactors that govern the formulation of plans, and solicitingrepresentative sample projects and historical information foruse as cases. Cases were available for both multi-storybuilding and major road construction projects. Highwaybridge construction was selected because it is representativeof both building and civil engineering works in sharingsimilar structural characteristics. The analysis of cases,and discussions with chief planners produced four mainclasses of factors that affect construction planning asfollows: the design, the specification, the constructionmethods; and the risk factors which affect project outcomes.Case information was provided by both the HighwaysAgency and by construction contractors. The formersupplied outline details of the test cases whilst the latterfurnished the detailed design and planning data which wasrequired.

4. Information modelling

There is currently a large amount of research effort oninformation modelling for the purpose of producingcommon standards as the basis on which to develop inte-grated systems. The key enabling technologies at the heartof current research are: the ISO-STEP 10303 [30] productmodelling initiative; the Industry Foundation Classes (IFCs)from the Industry Alliance for interoperability [31]; object

technology; and distributed computing standards. There-fore, it was deemed important to develop a CBR systemto potentially operate within an object-oriented integratedenvironment for design and construction in line with currentthinking [32,33]. This necessitated the production of amodel that reflected the total information requirements forthe problem as a pre-requisite. In order to establish theinformation requirements, a representative sample of high-way bridge construction projects and historical informationfor use as cases were obtained from practice. Discussionswith construction planners and examination of project docu-mentation indicated that the minimum information neces-sary for inclusion in the model is: structural designinformation describing a bridge and its components; activitylists with network planning data; dimensions and quantities;materials used; resources; risks identified; problemsencountered and methods used to overcome them; andcost data.

4.1. The information modelling methodology

The methodology for information modelling used for thisproject was Object Modelling Technique (OMT) [34]. Thisis an object-oriented modelling and design methodologythat uses three kinds of models to describe a system: theobject modelwhich describes the objects in the system andtheir relationship; thedynamic modelwhich describes theinteractions amongst objects in the system; and thefunc-tional modelwhich describes the data transformations ofthe system. Of these, the object model was primarily usedas it is the most applicable for depicting the knowledgerepresentation requirements of the system. In the ensuingsection, selected key object models are presented.

J.H.M. Tah et al. / Advances in Engineering Software 30 (1999) 495–509 497

Fig. 1. The IBridgePM top-level object classes.

4.2. The integrated bridge project model

An Integrated Bridge Project Model (IBridgePM) wasdeveloped to provide the basis for developing the data repo-sitory. It details the attributes and the inter-relationshipsbetween a bridge and its components and with the projectplan. The role of tasks, resources, risks, problems, and theirrelationships with the plan and project as a whole is alsodepicted. The attributes defined within the model form thebasis for the design of the case-bases.

The top-level object classes of IBridgePM are presentedin Fig. 1. The model shows that a project may contain one ormore products. A product can be a bridge or a building. Aproject can have one or more construction plans andresources. A construction plan is made up of tasks.IBridgePM consists of three sub-models namely: the bridgestructural components object model; the task object model;and the resource object model. The details of IBridgePMwill be presented under these sub-models in the ensuingsections.


Fig. 2. Bridge components object diagram.

4.3. The bridge components object model

The object diagram developed to model bridge compo-nents is shown in Fig. 2. This diagram is designed to allowthe modelling of all types of bridges, but currently the onlypath which was developed is that of beam bridges, whichappear to form the vast majority of bridges which are usedon highway projects throughout the UK. The three bridgetypes chosen, beam, arch, and suspension, are defined assuch by the manner in which they transfer the forces actingupon the superstructure into the substructure [35].

The final form of the object diagram was reached usinginformation from several sources. Amongst these sourceswere a number of key bridge texts [36–40]. Manuals and

reports from the Highways Agency [41,42], which commis-sions and maintains all structures, including bridges, asso-ciated with major road projects throughout the country,were also used. The Highways Agency also keeps a largedatabase (some 13 0001 records) of all the structures itmaintains which proved to be a good source of actual infor-mation.

4.4. The main bridge components

Beam bridges are composed of four main components:foundations, end supports, intermediate supports, and thedeck. Additionally, many end supports also have wingwallstructures associated with them. Object models of each of


Fig. 3. Deck object diagram.

Fig. 4. In-situ concrete components objects diagram.

these components were developed though, owing to spacerestrictions, only the deck OM is shown as an example, inFig. 3.

It is worth noting that the objects shown in Fig. 3, espe-cially those representing generalisations, are not meant toform an exhaustive list. Rather, the selections chosen are inkeeping with the type of construction which forms the basisof model implemented in this work, namely concrete struc-tures with the majority being reinforced concrete.

4.5. The basic bridge components

These, more commonly referred to as structural elements,are the building blocks of the main components which formthe structures themselves. There are a limited number ofthese, as they can be used in different combinations toform the main components. For the object model, thebasic components which are under consideration weredivided up into two groups: in-situ concrete components,and other components. Further expansion of the systemwill undoubtedly result in a refinement of these groups,with material types considered in greater detail. Theobject-oriented architecture of the system allows this to beachieved with minimal interference to the current model.

4.5.1. In-situ concrete componentsThese components are, arguably, the most important in

the model, as it is mainly from reinforced concrete compo-nents using which the main bridge components are formed.The in-situ concrete components object diagram is show inFig. 4. Note that each in-situ concrete component general-isation has a single non-inherited dimension attribute asso-ciated with it. This attribute is for use in quantity and costingcalculations. For example, the cost per unit area of aBasedepends on its thickness.

4.5.2. Other componentsTo aid the simplicity of the model, all non-in-situ

concrete components were placed into the other componentsgroup. While this could theoretically be quite a large group,it currently contains the ‘extra bits’ which add to theconcrete components to form the bridge. The other compo-nents object diagram is shown in Fig. 5.

4.6. The task object model

The object diagram developed to model project tasks oractivities is shown in Fig. 6. The task object model repre-sents the information required in the planning and control-ling of the production process. The task object is at thecentre of the construction project plan as it consists of oneor more construction planning activities or tasks. A task canbe assigned to one or many resources. A task can be affectedby risks, which may lead to problems if not properly mana-ged through the application of proper actions. The task classis sufficient for general planning systems as is typical ofcurrent packaged project management software. However,the task class is too abstract to facilitate knowledge-baseddecision support. Thus, the task class is specialised intomore concrete classes. A task can be a ‘‘work packet’’ ora ‘‘unit of work’’ (UoW). The ‘‘unit of work’’ class acts as abase class to more concrete units of work which may be ‘‘fixreinforcement’’, ‘‘erect formwork’’, ‘‘place concrete’’,‘‘strike formwork’’, etc. A work packet consists of multipleunits of work, and enables actual construction plans to bemodelled fully within the system.

4.7. The resource object model

The resource object model is shown in Fig. 7. Allresources are defined as plant, material, labour, gang, orsub-contractor. Within the model only material resourceswere specialised further, and the classes shown representonly those which are currently used. Further classes of mate-rials may be added as required.


Fig. 5. Other components object diagram.

5. The information repository

Given the large amount of both design and planninginformation available it is essential to define a data reposi-tory both to store the data and to facilitate informationmanagement and maintenance typical of a corporation.There are essentially two stores of information used bythe system – adatabasewhich contains all data detailingthe various system components and information asdescribed previously; and thecase-base, which containsessential elements of the database information distilledinto a concentrated form for the purposes of appropriatecase retrieval, adaptation, and re-use.

5.1. The database

Given the object-oriented nature of the system, the use ofan object-oriented database was considered, but wasrejected as previous experience has shown that, while theyare powerful tools, a large amount of time and effort isrequired for their full development. Instead, equivalententity-relationship diagrams [43] of the object modelswere produced and used to develop a relational database.Thus, the object-oriented models are mapped into a flatrepresentation for information storage within the database(this is shown in the upper part of Fig. 10).

The database is designed to store information of three


Fig. 6. The task object diagram.

different types: bridge and component outline design data;detailed design and planning information, including risks,problems, and corresponding remedial actions data; andresource data gathered from a standard source (for example,the CESMM3 price database [44]) or from corporaterecords.

The outline design data describes a highway bridge andthe components that form it, and eventually forms the basisfor the case-base. It effectively defines the specifications forthe bridge and components. The detailed design informationis linked to this, and explicitly defines the structuralelements that are associated with each component, describ-ing their design, specification, materials, dimensions, etc.The planning data includes all task information, includingassociated resources and network logic connections, and islinked to the design information via the component struc-tural elements. The task data files contain data relating toboth estimated and actual values. This allows the two sets ofinformation to be compared, enabling deviations from theplan to be determined. The task data is associated with risksand problems data files, which in turn are associated withthe remedial actions data file.

The standard resource data contained within the data filesis split into three categories: the procurement costs of indi-vidual material resources, in this case divided into concrete,formwork, steel and fabric reinforcement, and other mate-rial resources; the placement costs and times of the materialresources; and the details of labour, plant, gangs, and sub-contractors resources. Additionally, other data files detail

resource costs and efficiency ratings, for accurate calcula-tion of task durations and costs.

5.2. Case representation

Owing to the complexity of construction project informa-tion, as depicted in the models developed, the use of a singlecase-base was deemed inappropriate and a hierarchicalmultilevel strategy was adopted. This approach defines theglobal design features of a bridge as a case, with referencesto the individual sub-components that form it, the localdesign features of which are defined sub-cases. These sub-component cases are formed from the basic components asdescribed previously, and the basic bridge components atthe leaf nodes of the hierarchy provide the link to the actionsor tasks within a project, and hence the plan. These tasks inturn link to any risks envisaged, problems encountered, andany remedial measures that are planned or were taken. Thistree-like representation is consistent with work breakdownstructures, as are commonly used in construction planningin practice. Additionally, separately storing the various sub-components that form the bridge as sub-cases has the advan-tage that they can be accessed individually if necessary,which has positive repercussions at the case adaptationstage of the CBR process.

A case indexing scheme was developed to represent theglobal features for a bridge and the local features of its sub-components, with indices that allow a case to be differen-tiated from similar cases. Careful consideration was given to


Fig. 7. The resource object diagram.

the selection of relevant attributes. The analysis of construc-tion programme work breakdown structures and discussionswith chief planners indicated that the actions or activities ina plan are highly dependent on the design and specificationof a bridge and its component parts. Experience fromsuccessful case-based design systems indicate that the func-tion, behaviour, and structure attributes of designs, as inGero’s design prototype [18], provide good indices. Thus,

the attributes defined by the Highways Agency in theirbridge management database for highway structures wasadopted as these appear to cover the functional, behavioural,and structural features adequately. Relational attributeswere added to facilitate implementation of case hierarchiesas in CaseCAD [19] and CBRefurb [22]. Fig. 8 depicts anexample of case representation, and also shows the relation-ship between the bridge case and component sub-cases.


Fig. 8. An example of case representation.

Fig. 9. Example concrete component ART object.


Fig. 10. Data mapping from the object models.

6. CBRidge planner prototype implementation

Prototype software,CBRidge Planner, was developedusing Brightware’s ART*Enterprise (AE) developmentenvironment operating under Microsoft Windows. Itdemonstrates case storage, retrieval, adaptation, and re-use. A summary of these, together with the manner inwhich the data in the relational database is mapped to theobject models in AE, are presented in this section. Fulldetails of the operation of the system cannot be presentedhere owing to space restrictions, and readers are referred toTah et al. [45] for further information.

6.1. Mapping the database files to ART objects

ART*Enterprise is a fully object-oriented developmentenvironment, and as such the conceptual object modelsproduced can be represented within the system. However,owing to the use of a relational database to store the projectdesign and planning data, it is necessary to map the flatinformation representation into a hierarchical object systemwithin ART*Enterprise. Accessing the relational data filesis simplified by the use of ART*Enterprise’s data integrator[46], which is able to read, write, and query the database viaMicrosoft ODBC. The data integrator (DI) takes one ormore data files and creates a mapping instance allowingthe data contained within the files to be imported asinstances of a created DI object within the system. Fig. 9shows an example of an imported object instance, in thiscase a concrete base.

The created DI objects are generated automatically byART*Enterprise depending on the database type fromwhich the information is to be mapped, and the number ofdata files which must be mapped from. Owing to this auto-mated mapping process, the generated objects do not followthe models as defined, and thus the imported data is notrelated in the hierarchical object format. To overcomethis, further objects are created in the system which

explicitly follow the form of the object models, and theimported data is then mapped from the generated DI objectsto the hierarchical objects. This allows the imported data-base information to be stored and manipulated in a way thattruly reflects the developed object models, as shown in thelower portion of Fig. 10.

6.2. Case retrieval, adaption, and re-use

The case-base requires data from some source initiallyand, given the nature of the data repository, it was decidedthat the database would be ideal for this purpose. CBRidgePlanner is able to query the database for appropriate cases,split into the bridge and its components, which are thenstored in their appropriate case-bases. Case retrieval isperformed on the case-bases, using design level informationas a match. Given the hierarchical multi-level nature of thecase-base, multiple cases are retrieved and an algorithmproduces a total score for each full bridge case, dependingon its component sub-cases. The retrieved cases are thenrank ordered by score, enabling a considered decision tobe made as to which case will be selected and retrievedfor subsequent adaptation and re-use.

The database and the case-base operate in tandem in thesystem. The cycle of the case storage and retrieval process,showing the relationship between the database and the case-base, is given in Fig. 11. The design data for the bridge andits main components are used to form the cases initially.When case retrieval is successful, the planning data appro-priate to the case can be retrieved from the database to forma full case for subsequent adaptation and re-use.

The adaptation process is split into two stages; designadaptation and planning adaptation. During the former, theuser selects and replaces weak components within theretrieved case. This is aided by the modular multi-levelcase-base structure, which allows a case to be constructedfrom several parts, the match score representing a weightedsum of the individual match scores of these parts. Thus, if


Fig. 11. The case storage, retrieval, adaptation, and re-use lifecycle.


Fig. 12. CBRidge planner during design adaptation.

Fig. 13. Linking CBRidge planner to a planning package.

one or more of the components are badly matching, thenthese can be replaced by more suitable ones from the case-base. Fig. 12 shows CBRidge Planner during the designadaptation stage.

Planning adaptation is more involved, and can be roughlysplit into three parts: accessing the data files for all relevantdetailed design and planning data; updating any networkconstraints which were violated during design adaptation;and calculating all associated quantities, costs, and times foradaptation of the data to the new bridge. The data repositorycontains information relating to the modified bridge and itscomponents, such as detailed bridge and componentdescriptions, structural element data, task and resourceinformation etc., and this needs to be accessed for thepurposes of adaptation. Additional information is alsorequired to enable the system to repair any networkconstraints which may have been violated during the designadaptation process. Once this was completed all tasknetwork data, such as quantities, durations, and costs,need to be determined. Currently only cast in-situ concretestructural elements are catered for in the calculations, asthese from the primary structure in the selected projects.The structural elements and their associated tasks are iden-tified, allowing quantity, time, and cost calculations to beperformed. Once done a full network analysis is alsocompeted, allowing all standard network data to be calcu-lated. The data can then be back-propagated throughout thework breakdown structure, enabling durations and costs tobe determined at each level. Following this, adaptation ofthe data for use on the new bridge can commence. This isbased on the information which was calculated but withmodifications made owing to the differences between thetwo projects. CBRidge Planner uses a scoring algorithm toassociate structural elements in the modified bridge withstructural elements in the new bridge, allowing CBRidgePlanner to map the tasks from one bridge to the other.Certain items of data within the tasks, such as materialquantities, resource times and costs etc., are project specific.To overcome this, algorithms were developed to determinethe differences between the two bridges, such as materialuse and type, quantities, and dimensions. These differencescan then be applied as modifiers to the task data during themapping process.

The whole case retrieval and adaptation process producesas-plannedinformation for a new project. The intention is togather post-project information, such as problems encoun-tered and remedial measures used, and use this to produceanas-builtcase. This can then be added to the case-base forfuture re-use, thus facilitating the learning process. Inrecognition that one of the benefits of good planningis the visual plan, a link was developed to export gener-ated data to the Microsoft Project planning package, asshown in Fig. 13. This link enables task data, includingtask identifications and descriptions, durations, networklogic connections, resources, and costs to be exported andviewed graphically.

6.3. System validation

The prototype model was developed and tested usingdetailed information from 15 highway bridge constructionprojects. A further test project was gathered, and thisincluded all manual calculations for testing purposes. Test-ing was conducted at two main stages; case retrieval andcase adaptation. The first of these was to test that the mostappropriate cases were being retrieved from the case-bases,and was achieved by altering the attribute values of the testproject and applying it as a target case for match purposes.The values of the attributes were carefully selected andcontrolled to enable pre-selected ‘best’ cases to be retrievedgiven a properly functioning system. The results of thistesting process proved that CBRidge Planner was perform-ing as expected in terms of case retrieval. Case adaptationtesting was performed to ensure that the final output values,such as quantities, times, and costs, were correct. This wasachieved by comparing the results generated by CBRidgePlanner with manually computed values for the test case.The material component quantities, task durations, andresource group and material costs were compared. Thesystem generated results were as expected, with only veryminor differences. Note, the number of test samples mayinitially appear small, but each case has a large amount ofdata associated with it. Each bridge case has an average of100 tasks, plus all material, plant, labour, and sub-contractorresource information, details of the structural elements, plusrelevant risk and financial data. The number of examplesused was deemed appropriate for testing purposes, though itis acknowledged that a larger number would be more appro-priate in practice.

7. Discussion

The current version of CBRidge Planner was developedto test the ideas behind case storage and retrieval within theconstruction planning domain. However, there are a numberof areas in which further development would benefit thesystem. One such area which would be the reorganisationand definition of the attributes within each part of the bridgestructure. The current attributes defined for the main bridgeinformation and each of the components were ones consid-ered to be of greatest importance for initial development.Obviously the definition of importance varies between indi-vidual planners, and also from the perspective of the type ofplan used. The flexibility of the system would increase ifmany more attributes were defined for each part of thestructure, and each planner could decide which ones wereimportant, and what the individual levels of importanceactually were. This would greatly increase the customisa-bility of the system.

The object-oriented architecture of the system enables itto be expanded to cover non-concrete components and othertypes of work. The facility for the storage of such items


within the database exists, and the infrastructure is in placefor CBRidge Planner to import this data for use within thesystem. The inclusion of these items in the time and costcalculations is not a difficult task, so long as the requisitedata is available. Expansion of the system into constructiondomains other than bridges is an obvious long term devel-opment. This would require the development of objectmodels of other constructs to be included in the framework,as well as the treatment of different work types. This wouldbe a major undertaking, but would almost certainly benecessary for eventual practical use. To facilitate this, thedevelopment of a comprehensive user-defined case searchengine with a choice of output information would providethe greatest flexibility.

An additional area of consideration is the potential futureuse of the system. Currently the system data operates on twolevels; the outline design information, and the detailed plan-ning formation. If a project is to be entered into the case-base then both sets of information are required, whereas acase used for matching purposes requires the design infor-mation, plus some of the planning data. Thus, projects arerequired to be defined to a certain level before they can beused for match purposes, representing a limitation of thecurrent prototype. CBRidge Planner could feasibly berefined for use as a search tool, to help the user select anappropriate case given a minimal amount of starting infor-mation. As such, the user may begin with a few outline ideasabout the bridge structure, and use these to search the case-base for examples. The retrieved case list can be honeddown as more information is entered by the user, until asingle final case is available for modification. Rather thancomparing the retrieved bridge with an initial example, theuser instead suggests modifications, and the systemresponds by varying the plan costs, times, and quantitiesautomatically. Hence, a similar system to the present one,but rather more dynamic in terms of initial informationrequirements.

8. Conclusions

The work presented in this article is part of a largerresearch project aimed at investigating the extent to whichCBR can be applied to construction planning and control.This involves the use of a large amount of historical infor-mation that is often unstructured in practice. This articlepresents a conceptual project data infrastructure that repre-sents details of the information to be stored within a repo-sitory. This consists of a large number of conceptual objectmodels, which define the attributes and relationshipsbetween design and planning information comprehensively,using bridges as a representative product. The models expli-citly represent the roles of products and their componentparts, tasks, resources, risks, problems, and remedialactions.

The models were used to develop a large information

repository implemented in a database management systemto facilitate real world project information collation, orga-nisation, and management to reflect the large-scale nature ofconstruction projects in practice. The database acts as a datasource from which the cases are drawn for the purpose ofpopulating the case-base. A heirarchical multi-level strategywas adopted for the case-base, with cases consisting ofglobal data describing the bridge structures and local datadescribing the main components which form them. Thecases and sub-cases are considered individually for index-ing, matching, retrieval, and validation purposes, facilitat-ing the re-use of parts of multiple cases for the constructionof new solutions. A prototype software model, CBRidgePlanner, was developed and tested with real world bridgeproject cases to demonstrate the data infrastructure in prac-tice.

Acknowledgements

The support of the EPSRC in providing funding for thiswork under grant ref: GR/K26516 is gratefully acknowl-edged. The support of project managers and planners froma number of organisations, notably Balfour Beatty, JohnLaings, Trafalgar House, EC Harris, the ReinforcedConcrete Council, and the Highways Agency, in providinginformation for this work is also gratefully acknowledged.

References

[1] Brandon PS. Expert systems – after the hype is over. Proc. Int. Symp.on Building Economics and Management, 1990.

[2] Riesbeck CK, Schank RC. Inside case-based reasoning. Hillsdale, NJ:Lawrence Erlbaum, 1989.

[3] Watson I, Marir F. Case-based reasoning: a review. The KnowledgeEngineering Review 1994;9(4):327–354.

[4] Marir F, Watson I. Case-based reasoning: a categorised bibliography.The Knowledge Engineering Review 1994;9(4):355–375.

[5] Hammond KJ. Case-based planning: viewing planning as a memorytask. New York: Academic Press, 1989.

[6] Kolodner J. Judging which is the ‘best’ case for a case base reasoner.In: Case-based reasoning. Proc. Workshop in Case-Based Reasoning,Florida, Morgan-Kaufmann, 1989, pp. 221–228.

[7] Veloso M. Learning by analogical reasoning in general problemsolving. Ph.D. Thesis, School of Computer Science, Carnegie MellonUniversity, Pittsburgh, PA, 1992.

[8] Munoz-Avila H, Huellen J. Retrieving cases in structured domains byusing goal dependencies. Proc. First Int. Conf. on Case-BasedReasoning, Sesimbra, Portugal, 1995, pp. 241–252.

[9] Faltings B, Hua KF, Schmitt G, Shih SG. Case-based representationof architectural design knowledge. Proc. DARPA Case-BasedReasoning Workshop, 1991, pp. 307–316.

[10] Shih SG. Case-based representation and adaption in design. In:Schmitt GN, editor. CAAD futures ’91, Braunschweig: ViewegVerlag, 1991, pp. 301.

[11] Pearce M, Goel AK, Kolodner J, Zimring C, Sentosa L, Billington R.Case-based decision support: a case study in architectural design.IEEE Expert 1992;7(5):14–20.

[12] Domeshek E, Kolodner JL. A case-based design aid for architecture.In: Artificial intelligence in design ’92. Dordrecht: Kluwer AcademicPublishers, 1992, pp. 497–516.


[13] Schmitt GN. Case-based reasoning in an integrated design andconstruction system. International Journal of Construction Informa-tion Technology 1993;1(3):31–51.

[14] Flemming U. Case-based design in the SEED system. Automation inConstruction 1994;3:123–133.

[15] Rivard H, Fenves SJ, Gomez N. Case-based reasoning for conceptualbuilding design. First Int. Conf. New Information Technologies forDecision Making in Civil Engineering, Montreál, Canada, October1988, pp. 355–366.

[16] Borner, K. Modules for design support. FABEL-Report No. 35,Centre for Cognitive Science, University of Freiburg, Germany,1995.

[17] Iliescu S, Fazio P, Gowri K. A case-based reasoning framework forpreliminary building envelope design. First Int. Conf. New Informa-tion Technologies for Decision Making in Civil Engineering,Montreal, Canada, October 1988, pp. 401–412.

[18] Gero JS. Design prototypes: a knowledge representation schema fordesign. AI Magazine 1990;11(4):26–36.

[19] Maher ML, Garza AG. Developing case-based reasoning for struc-tural design. IEEE Expert 1996;:42–52.

[20] Yang S, Robertson D. A case-based reasoning system for regulatoryinformation. Proc. IEE Colloq. on Case-Based Reasoning: Prospectsfor Applications, Digest No. 1994/057, 1994, pp. 3/1–3/3.

[21] Watson ID, Abdullah S. Developing case-based reasoning systems: acase study in diagnosing building defects. Proc. IEE Colloq. on Case-Based Reasoning: Prospects for Applications, Digest No. 1994/057,1994, pp. 1/1–1/3.

[22] Marir F, Watson I. Representing and indexing building refurbishmentcases for multiple retrieval of adaptable pieces of cases. Proc. FirstUnited Kingdom Workshop on Progress in Case-Based Reasoning,Salford, UK, 1995, pp. 55–66.

[23] Ng ST, Smith NK, Skitmore RM. A case-based reasoning model forcontractor prequalification. International Journal of ConstructionInformation Technology 1998;6(1):47–61.

[24] Brandon P, Ribiero FL. The assessment of applications for the houserenovation grant system (HRGS) – a multistrategy knowledge-basedframework. Journal of Engineering, Construction and ArchitecturalManagement 1997;4(1):41–57.

[25] Dutton D, Maun K. Case-based reasoning for materials selection indesign. International Journal of Construction Information Technology1997;5(2):103–111.

[26] Moore CJ, Lehane MS. Development of a case representation strategyfor a bridge design case base. Engineering Structures 1999;21(3):219–231.

[27] Kawooya AAO, Aouad G. Case-based integrated construction plan-ning. First Int. Conf. New Information Technologies for DecisionMaking in Civil Engineering, Montreál, Canada, October 1988, pp.137–145.

[28] Tommelein ID, Dzeng R-J. Automated case-based scheduling forpower plant boiler erection: use of annotated schedules. Proc. 11th

Int. Symp. of Automation and Robotics in Construction, ElsevierScience, Amsterdam, 1994, pp. 179–186.

[29] Brown M, Watson I, Filer N. Separating the cases from the data:towards more flexible case-based reasoning. Proc. First Int. Conf.on Case-Based Reasoning, Sesimbra, Portugal, 1995, pp. 157–168.

[30] ISO TC184 STEP Part 1: Overview and fundamental principles.Industrial Automation Systems and Integration-Product Data Repre-sentation and Exchange, International Standards Organisation (ISO),Geneva, Switzerland, ISO DIS 10303-1, 1992.

[31] IAI (Industry Alliance for Interoperability); http://www.interoperabil-ity.com/.

[32] Tah JHM, Howes R, Wong HW. Towards a concurrent engineeringenvironment for integration of design and construction (CEE-IDAC).Proc. First Int. Conf. on Concurrent Engineering in Construction, TheInstitution of Structural Engineers, London, 3–4 July 1997, pp. 206–215.

[33] Fox S. Why use object-oriented project management? First Int. Conf.on New Information Technologies for Decision Making in Civil Engi-neering, Montreál, Canada, October 1988, pp. 157–168.

[34] Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorenson W. Object-oriented modeling and design. Englewood Cliffs, NJ: Prentice-Hall,1991.

[35] Troitsky MS. Planning and design of bridges. New York: John Wiley,1994.

[36] BRE Bridge Foundations and Substructures. BRE Report, HMSO,1979.

[37] Cusens AR, Pama RP. Bridge deck analysis. New York: John Wiley,1975.

[38] Liebenberg AC. Concrete bridges: design and construction. NewYork: Longman Scientific and Technical, 1992.

[39] Pennells E. Concrete bridge designer’s manual. Viewpoint Publica-tions, 1978.

[40] Xanthakos PP. Theory and design of bridges. New York: John Wiley,1994.

[41] Highways agency design manual for roads and bridges; Volume 3:Highway Structures Inspection and Maintenance; Section 1: Inspec-tion; Part 4: Inspection of Highway Structures. BD 63/94, HMSO,1994a.

[42] Highways agency design manual for roads and bridges; Volume 3:Highway Structures Inspection and Maintenance; Section 2: Mainte-nance; Part 1: As Built, Operational and Maintenance Records forHighway Structures. BD 62/94, HMSO, 1994b.

[43] Chen PS. The entity-relationship model – toward a unified view ofdata. ACM Transactions on Database System 1976;1(1):9–36.

[44] EC Harris. CESMM3 price database 1993/94. Thomas Telford, 1993.[45] Tah JHM, Carr V, Howes R. An application of case-based reasoning

to the planning of highway bridge construction. Engineering,Construction and Architectural Management 1998;5(4):327–338.

[46] Brightware ART*enterprise manuals. Novato, CA: Brightware Inc.,1995.


Documents

Information modelling for case-based construction planning of highway bridge projects