Back Home Next
ASC Proceedings of the 41st Annual Conference
University of Cincinnati - Cincinnati, Ohio
April 6 - 9, 2005         
 
Structuring Construction Data for use in a Case Based Reasoning Shell for Construction Estimating
 
Craig D. Capano, MCSM, CPC
Western Carolina University
Cullowhee, NC
 
Saeed Karshenas, Ph.D., PE and
Craig A. Struble, Ph.D.
Marquette University
Milwaukee, WI
 
Construction cost estimating is the process of gathering all available information in order to forecast, with some degree of accuracy, the cost of work that will be put in place on a project. The forecast is best achieved by comparing past project information with the new project requirements. This paper will explore the creation of case structures as a solution to gathering and maintaining historical costs. It will also explore the use of a Case-Base Reasoning shell, which could be utilized to standardize collection and analysis of data. This type of system could potentially increase the accuracy of estimating by applying heuristic and probabilistic analysis to the captured case data. New information is used to compute similarity and to adapt a retrieved similar case to better meet the needs of the new problem. This “artificial intelligence” could assist in performing the subjective and indeterminate analysis work now carried out, but often not captured, by estimators.
 
Key Words: Artificial Intelligence, Data structure, Case Based Reasoning, Estimating
 
 
Introduction
 
Collection and retrieval of historical cost data is paramount in the development of estimates for construction work. This process is often critical because award of contract is predicated on the lowest qualified cost to complete the project. An estimator must make the cost forecast based on a number of deterministic attributes of a project but also, and more difficult to determine, a number of subjective determinations of that project. Because of these requirements, a simple data retrieval model is not a useful tool in querying and compiling costs. The most successful tool would be one that could query past projects and identify costs based on the experiences that were encountered in that particular project. In order to accomplish this it is believed that a tool based on Artificial Intelligence, specifically Case Based Reasoning, could be the best approach.
 
Artificial Intelligence (AI) can be considered as tools that emulate human thought to help in solving problems. The academic definition of AI states that it is the subfield of computer science that focuses on the computer’s ability to manipulate nonnumeric symbols and infer new facts from sets of known facts (Carrico, 1989). A more practical definition is "Artificial Intelligence is the study of ideas that enable computers to be intelligent" (Winston, 1984). The goal of AI can be to make computers more useful. Carrico stated that the term artificial intelligence covers a broad range of areas (Figure 1).
 
Branches of Artificial intelligence
 
Figure 1. Branches of Artificial Intelligence (AI) (Carrico, 1989)
 
The five branches of AI are derived from cognitive science (Carrico, 1989). Cognitive science is the field of study that seeks to understand and mimic human mental processes. This is the science that fuels the fields of AI.
Knowledge systems are software systems that have structured knowledge about a field of expertise. They are able to solve some problems within their domain by using knowledge derived from experts in the field. This approach emphasizes data interpretation.
Knowledge systems could prove useful in organizing and structuring data for construction estimating. These systems can be applied to any kinds of knowledge in order to solve problems within their domain. There are several approaches using knowledge in solving problems of various domains. These include rule-based expert systems, model-based reasoning (MBR) (Davis and Hamscher, 1986), and case-based reasoning (CBR) (Slade, 1991).
Rule-based expert systems and MBR have been discussed for use in construction but have encountered some limitations (Adeli, 1988). These limitations are largely based on the static constraints of algorithms.  Unlike rule-based expert system and MBR, where the decision making process is encoded strictly in explicit and static rules or algorithms, CBR systems may learn from previous experience (by example) and can continue the learning process as they are used and develop. CBR systems are characterized as systems that learn from example or their environment, and may store the knowledge gained either explicitly as cases, or implicitly, as a compiled or emergent representation of their perceived environment (Aha, 2001). It is this model which will be explored for this discussion.
 
A CBR methodology for construction cost estimating is proposed in this paper. Due to the high variability in type, size, and complexity of construction projects this paper concentrates on the use of the technique for information re-use in construction estimating for a CMU (Concrete Masonry Unit) block wall. Object models for the CMU block wall and its components were formed, and used to develop a prototype application using CBR-Works, a commercially available CBR shell. The application takes wall construction information and adds it to cases that can then be used for case matching. Once a suitable case has been found it can be adapted to more closely match the new project, and following this the adapted case could be linked to an estimating database, enabling the estimator to use the historically matched case for use with current project. It concludes by discussing the benefits of this approach and the limitations of the system, together with future directions.
 
 
Defining CBR in Construction Cost Estimating
 
Construction cost estimating has traditionally been a function that requires a great deal of experience and understanding of the building process. It has often been referred to as both an “art” and a “science”. The science is the quantification of the materials, equipment, and labor. The art of estimating included the intangibles or indeterminate affects of the unknowns that are experienced and quite prevalent, such as weather, productivity, and risk. It is this mix of reference that makes estimating a difficult process to model using traditional rule-based algorithm.
 
When attempting to define the process in an estimating system it is often difficult to account for all of the attributing factors. Some of the indeterminate factors arise because the project is not built in a statically controlled environment and each project posses its own changes and unique problems. The system determinates require a degree of subjective analysis and inferences that are often referred to as the “art” of estimating. The ability to successfully identify these factors and to account for their effects on the cost, often takes years of practice and experience. The estimating “experts” draw from past experience and cases in order to compare values to unknowns. It is possible to learn the tools and techniques for estimating and data modeling, but using those tools and techniques is an art that requires experience guided by intuition (Kroenke 2000).
 
Because cost studies of individual projects are based on historical costs and intuitive adjustments, it is only natural to explore how CBR could contribute to the effort. Representing a project or a particular work package of a project, as a multi-dimensional case, could elucidate the issues involved and the decisions required for costing. Past experiences with real projects could be queried to find beneficial costs which are similar, along one or more dimensions, to old ones. The long- term goal is to make the computer a full member of the estimating team. While this work is preliminary and the issues to explore are numerous, the potential to integrate state-of-the-art adaptive learning systems, while making a significant real-world contribution, is great.
 
Developing the Case Structure
 
A CBR shell was used to develop and test case structures and retrieval queries. An evaluation copy of CBR-Works 4, developed by Empolis, Inc., was used to build the model case for a typical Construction Masonry Unit (CMU) wall. The evaluation copy has most of the functionality offered in their commercial product except for the ability to use the program through a web interface.
 
The CMU building component is used extensively in construction and is generally found in all types of building projects including residential, commercial, industrial and civil projects. For this study walls and their attributes associated with commercial construction projects were examined. Further research could develop attributes and cases that may be used in querying other types of construction material assemblies.
 
The general parameter of this case structure is to form an intelligent query tool for matching similar walls that have been constructed in the past on a variety of projects. The domain chosen is estimating the costs of CMU walls. The purpose of this domain is twofold and is intended to:
 
1. Represent walls, i.e. the relevant materials and equipment used in a wall construction.
2. Represent uncertainties, i.e. the constraints and parameters that effect assembly.
 
Building a CBR System

 

CBR-Works 4 allows the user to build cases from a host of attributes used to model cases. In order to develop a CBR System a number of factors and decisions concerning the domain must be made. These can be classified in the following functions (Technico, 2000):
bullet
Case (product) definition (domain model) – This requires the user to define the knowledge and representative attributes related to the specific case.
bullet
Initial case (product) acquisition - A model is prepared and simulated using the software tools.
bullet
Tuning the parameters of the CBR system: cases indexing, similarity definition – This step requires an assessment of the parameters established. It allows for adjustments of similarity and rule interpretations.
bullet
Customizing User Interface – Although not included with the evaluation edition of CBR-Works 4, this function allows the model to be interfaced with intelligent web applications.
bullet
Setting up an organization for case (product) acquisition, model changes, quality control modeling – This is the final step in the development and implementation of the model. It relates to the functionality and use of the system and developing the work structures and data modeling for incorporation. This function will also not be explored with this software edition.
 
CBR-Works is a modeling tool with the purpose (Technico, 2000):
bullet
To get insights into the techniques, difficulties and possibilities of modeling cases.
bullet
To get insights to the problem for deciding when such an approach can be recommended.
bullet
To get a first feeling in the complexity of developing such a querying tool.
 
For the example, a CMU wall model may include definition of domain and case parameters built around the following: 
bullet
An 8” thick CMU wall is required.
bullet
However, an insulated one would be better.
bullet
Walls that were built during specific times of year should be distinguished.
bullet
Aesthetics are an important factor (Block type, Bond, Tooling).
 
Size limits specifications (Long wall requires more control joints, over 5’ requires scaffolding, ect…..)
 
These are but a few of the determinations that must be made in describing the wall for this case. These are also only some of the attributes needed by the estimator when evaluating similarity between cases.
 
 
The Object Model
 
In order to identify and capture the information relevant to the cost of the CMU wall, a model must be developed that will reflect the critical information required for comparisons. Once the basic attributes and relationships have been determined, weighting of these factors can be implemented. This weighting will have an affect on the model by allowing the user to refine queries based on relevancies and the level of uncertainties assigned.
 
The development of the case structure for the CMU wall must include some description of the requirements and attributes associated with the wall. The following procedures for developing the case were established: 
bullet
Think of the intended CMU wall and describe the wall classes in natural language.
bullet
Transfer this into a formal representation, i.e. describe the CMU wall classes using attributes and predicates.
bullet
On this basis model the concept wall by:
bullet

Introducing attributes and their types that apply to CMU walls

bullet
Indicate which attributes are mandatory and/or can be discarded
bullet
Define relevancies in terms of weights
bullet
Define local measures
 
For the CMU wall an example case was defined in natural language as follows:
 
Wall Class Masonry Wall
 
This refers to a Masonry Wall that can be built from brick, block, or stone. But each type requires some common attributes (date built, height, length, access, productivity, crew, and risk). This example will be based on the attributes for a CMU (Concrete Masonry Unit) Block wall. Each block wall construction is influenced by the block (size, type, and whether or not it is interior or exterior), bond pattern, jointing requirements (tooling type, and mortar type), reinforcing requirements (horizontal and vertical), number of pilasters, frequency of corners, insulation requirements, and amount of openings). Additionally each block wall must be defined as above or below grade. Below grade may or may not require damproofing. Above grade may or may not require scaffolding (Schuette, 1993).
 
It is understood that there may be a host of additional factors and attributes that affect the construction of the wall. However for this example the factors will be limited to those identified.
 
The description was then transposed into a representative set of object-oriented models using attributes and predicates. The root of Masonry_Wall was defined using the subset of classes and relationships to define the attributes. As shown by Figure 2 the case illustrates the components and variables needed to store cases for a CMU wall. For this example only a CMU Block_Wall was expanded. Each attribute was further defined as a specific type.
 
In order to develop the model for this case structure, ObjectStore Database Designer was used. This tool is generally used for the development of cases in C++, but was found to work well in defining this case, object, related relationships and attributes, as they will be applied to CBR-Works. This modeling technique is based on Rumbaugh’s object modeling technique (Rumbaugh, 1991) to represent case knowledge.
 
 
Figure 2: Masonry Wall Case
 
This information can then be used as the bases for the case model in CRR-Works. The next step is to manually transfer this information to the Concept Manager component in CBR-Works.
Applying Case Structure to CBR-Works
 
CBR-Works 4 is a tool that uses CBR for diagnostic support, information retrieval and product selection. It supports the use of existing databases as knowledge sources. However, the evaluation copy did not include the functionality of web integration. 
 
When developing a model to evaluate cases, a new case must be defined. The following Figure 3 is the opening screen for CBR-Works 4.0. The Concept Manager is launched and the data is entered in the page defining the properties.
 
 
Figure 3: CBR-Works Concept Manager
 
Next, each case concept must be modeled in CBR-Works using attributes and relations. As can be seen from the following example in Figure 4, each attribute can be defined as a Name, Type, Discriminate, Mandatory, Weighted and even multiple languages.
 
Objects are presented in attribute-value description. Questions defining attribute properties are established. These questions will be posed when running the query and they set the parameters for interaction.
 
 
Figure 4: Defining Attributes
 
The need to define all attributes is not necessary. The program will function with little information. However, the more data that can be provided in the query mode, the greater the similarity algorithms will define a solution. Even if the input is incomplete (because as a user you may not be sure about your demands) CBR-Works will accept your query and give you an answer using the most successful similarity search.
 
 
Defining Cases and Querying
 
Once objects and types have been developed and attributes assigned with related functionalities, new cases can be created that will be used to build the database for query. For the CMU wall example a number of cases were developed and titled as “jobs”. These could represent all the projects in which the company built this type of wall system.
 
Figure 5 illustrates how the various projects could be classified based on their object definitions. It also indicates the attributes that must be defined as the case is being built.
 
 
Figure 5: CMU Block Wall Case
 
In this example the wall is being defined as one that is “Above Grade”. All attributes and relations associated with this object are inherited from all associated objects. Attribute definitions are required to be entered by the user. Each attribute is associated with a pick-box that appears when the attribute is selected. These boxes are defined when the types were developed and are quite easy to select and enter data from. They also include the questions that were developed in order to prompt the user for input. In the event that the user cannot define the attribute, it will be assigned an “undefined” value but will be stored in the case regardless.
 
 
Consulting the Case Base
 
Similar to the case definition function, the user must define the attributes that are going to be queried from the database. Figure 6 is an example query of an Above Grade Wall.
 
 
Figure 6: Query of Above Grade Wall
 
The query returns the cases in an ordered sequence based on the highest level of similarity. The similarity is computed based on the algorithms built in the program and also the assignment of weighting and attribute importance by the user.
 
For this example Job 1122 was returned from the database as having the highest degree of similarity with a .913 rating. A 1.0 similarity rating is considered a perfect match.
 
The calculations are based on the available information about the case. As can been seen by this example, both jobs have missing or incomplete attribute definitions. The algorithm performs a best match based on the information provided and disregards the undefined. This could pose a problem when applying the model to a project. The data that has been omitted may be crucial for price determination, but the user would not have the information available when making a cost determination.
 
 
Conclusion
 
CBR-Works as a CBR tool proved beneficial for this research. It allows a user to define objects, relationships, attributes and types in a process. There is a great deal of functionality that can be built into the models. The ability to query data and cases appears quite powerful and successful in evaluating and identifying similarities. Also, though not tried with this model, it appears that “outside” databases can be related to the query for increased capacity and options. The ability to access the program and databases using a web-based interface also seems to be a good option, although not available in the evaluation license.
 
Current construction estimating systems such as WinEst and Timberline lack a systematic approach to capturing and storing past costs and particularly the attributes that were encountered, as a complete historical database case for future use. This means that estimates have to be produced from scratch virtually every time a new project is to be estimated. The potential for the use of CBR for estimating the costs of construction for a CMU block wall has been examined and appropriate object models have been developed, along with a database repository for project information and a prototype solution based on a CBR software shell was presented. It has successfully demonstrated case representation, storage, and retrieval in an adaptive system that could retrieve similar cases for use in developing a new construction estimate.
 
The model developed for this research is intentionally simple and by definition limited. The types and attributes were selected as important given the requirement of simplicity. It is recognized however that the definition of importance will vary from estimator to estimator. Therefore it would appear to be better from the point of view of flexibility, if many attributes could be defined for each case and each estimator could select those judged to be important. As illustrated in the example, this could be done using weighting criteria, but would need additional definition and greater interface functionality.
 
Additional, the researcher noted that true learning capabilities of this software, was limited. It was hoped that there would be more functionality of the system to intuitively learn and recommend alternates. However it was limited by the algorithm established and did nothing to learn from mistakes. A study of additional CBR shells may reveal greater adaptability. Further developments and study in AI such as evolution algorithms, may also prove greater adaptability for use in construction estimating.
 
 
References
 
Adeli, H. 1988. Expert Systems in Construction and Structural Engineering, Chapman & Hall
 
Aha, D.W., Breslow, L.A., & Muñoz-Avila, H. 2001. “Conversational Case-based Reasoning”. Applied Intelligence, 14, 9-32
 
Carrico, M. A., Girard, J. C. and  Jones, J. P. 1989. Building Knowledge Systems, McGraw-Hill Book Co., New York.
 
Davis, R., and Hamscher ,W., 1986. "Model-based Reasoning: Troubleshooting", Exploring Artificial Intelligence, Morgan Kaufmann publishers, Inc., pp. 239-346.
 
Karshenas, S., and Tse, J., 2002. "A Case-Based Reasoning Approach to Construction Cost  
 
Estimating" Proceedings of the International Workshop on Information Technology in Civil Engineering, Washington, D.C.
 
Kroenke, D. M., 2000. Database Processing: Fundamentals, Design and Implementation. Upper Saddle River, N.J., Prentice Hall.
 
Richter, M., 2001,  Knowledge Containers. ICCBR, Vancouver, BC.
 
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Loresnson, W., 1991, Object-Oriented Modeling and Design, Prentice Hall.
 
Schuette, S. L. and Liska, R. 1994. Building Construction Estimating, McGraw Hill.
 
Slade, S., 1991, "Case-Based Reasoning: A Research Paradigm", AI MAGAZINE, vol. 12,
pp. 42-55.              
 
Tecinno, 2000.  CBR:Works - Getting Started.
 
 Winston, P.H. 1984. Artificial Intelligence, 2nd Ed., Addison-Wesley publishing Co.