1

A General-Purpose Situational Simulation Environment for Construction Education

(Manuscript CO/2003/022795)

Eddy M. Rojas1 and Amlan Mukherjee2

CE Database Subject Headings: Simulation, Models, Construction Management, Engineering

Education, Computer Aided Instruction.

ABSTRACT

The traditional construction education model based on precise, well-defined problems and formal

definitions is not satisfactorily fulfilling its mission of educating the decision-makers of tomorrow. This

realization has moved several researchers to explore alternatives where problem solving is carried out in

conjunction with the environment and concepts are embedded in the context promoting learning within

the nexus of the activity. Several efforts have been undertaken to develop these environments resulting in

a variety of special-purpose situational simulations. However, special-purpose situational simulations

exhibit inherent limitations related to their application breadth, flexibility, and promotion of

collaborations. These limitations cannot be resolved within the framework of special-purpose learning

environments. A general-purpose environment is required to overcome these shortcomings and take full

advantage of the situational learning paradigm. This paper describes the conceptual framework and pilot

implementation of such an environment called the Virtual Coach.

INTRODUCTION

The introduction of authentic practice in construction education has always been challenging. McCabe et

al (2000) argue that current civil engineering coursework teaches only the theories of construction

1 Assistant Professor, Department of Construction Management. University of Washington. 116 Architecture Hall, Seattle, WA 98195-1610. E-mail: er@u.washington.edu 2 Graduate Student, Department of Civil Engineering. University of Washington. 116 Architecture Hall, Seattle, WA 98195-1610. E-mail: amlan@u.washington.edu

2

management and that students may encounter difficulties applying these theoretical principles when

exposed to real world situations upon employment. Sawhney et al (2001) sustain that civil and

construction engineering curricula does not allow the inclusion of issues of importance to construction,

nor the participation of practitioners or hands-on experience. AbouRizk and Sawhney (1994) recognize

that traditional teaching methods are not fully capable of providing students with all the skills necessary

to solve real-world problems encountered in construction or conveying complex engineering knowledge.

If construction education does not provide students with the skills to solve “real-world” problems or to

apply theoretical concepts to practice, then one could question the effectiveness of the problems studied

or the methodologies applied.

Traditional construction education follows the Cartesian view of mind-matter dualism (Barab et. al 2001)

where the learner and the learning context are detached. Under this paradigm, concepts are presented as

fixed, well-structured, independent entities. Activities are divorced from their authentic context resulting

in fragmentation and specialization of courses and educational experiences. This fragmentation of

knowledge has been identified in the construction domain (Chinowsly and Vanegas 1996, Fruchter 1997)

and is partially responsible for the polarization of learner and learning context. Decontextualized

knowledge is intrinsically frail as demonstrated by students that are capable of recalling information on a

test, but unable to apply the very same concepts in authentic practice even when the situation clearly

merits such an action (Brown et al 1989). Another example of this fragility can be observed in school

when students neither retain nor are able to utilize knowledge allegedly acquired in previous courses

(Bertz and Baker 1996). These problems, of course, are not exclusive to construction education, but

shared by most higher education models.

Separating the learner from the learning context can cause the knowledge itself to become inert and

irrelevant due to the elimination of the natural complexity of content, the oversimplification of relations,

and the absence of authentic problem solving and inquiry; creating the ancillary effects of stifling

3

creativity and diminishing enthusiasm (Barab et. al 2001). Case studies and construction site visits have

been used by construction faculty as a means to generate usable and robust knowledge with partial

success. However, case studies can give the impression that there are easy-to-find and universally

correct responses due to the necessary simplifications (Pennell et al 1997) and site visits of large groups

to construction sites may not be welcome, involve risk, and be unpractical (Echeverry 1996).

The traditional construction education model based on precise, well-defined problems and formal

definitions is not satisfactorily fulfilling its mission of educating the decision-makers of tomorrow. This

realization has moved several researchers to explore alternatives where problem solving is carried out in

conjunction with the environment and concepts are embedded in the context promoting learning within

the nexus of the activity. These efforts have led to the generation of gaming and simulation environments

such as Superbid (AbouRizk 1993), STRATEGY (McCabe et al 2000), and VIRCON (Jaafari et al 2001).

These systems constitute a natural evolution from earlier efforts such as CONSTRUCTO (Halpin 1970)

and AROUSAL (Ndekugri and Lansley 1992). These special-purpose situational simulations represent

the first step toward the implementation of a participatory, contextually rich paradigm in construction

education. Special-purpose simulations, however, present several limitations including reduced

application breadth due to its restricted scope, reduced flexibility due to lack of programmability, and the

inability to promote creation of new simulations and collaboration among developers. This paper

introduces a model for a general-purpose situational simulation environment in construction education to

overcome these limitations.

RELEVANCE: THE NEED FOR A GENERAL-PURPOSE ENVIRONMENT

Situational learning can be defined as the constructivist pedagogical approach where learners build

understanding through rich environments that encourage explanation and discovery and where teachers

change their role from telling students correct answers to guiding their actions in activities that embody

personally meaningful and practically functional representations (Barab et. al 2001). In situational

4

learning environments knowledge is intrinsically linked to its context encouraging rich conceptual

understanding through the examination of apparent paradoxes and unfathomable relations. This paradigm

is in clear antagonism to archetypal school activity and may even represent an anathema for those

accustomed to the didactic, lecture-based models. However, the utilization of active learning approaches

has been recognized as a fundamental strategy to restructuring engineering education (NSF 1995) as

students learn more effectively and permanently when they can actively participate in the learning process

(Chi et al 1989).

Situational simulations can be either special-purpose or general-purpose in nature. However, special-

purpose situational simulations exhibit inherent limitations related to their application breadth, flexibility,

and promotion of collaborations. These limitations cannot be resolved within the framework of special-

purpose learning environments. A general-purpose environment is required to overcome these

shortcomings and take full advantage of the situational learning paradigm. In terms of application

breadth, special-purpose situational simulations target a narrow domain. This domain is usually

circumscribed by selected case projects and scenarios. In other words, the systems based on this model

cannot be easily expanded without re-engineering their computational engines. The situations

experienced by the learners are also confined to the scenarios that have been pre-programmed within the

tool. General-purpose situational simulations, on the other hand, target a very broad domain and can be

used to model almost any kind of situation. There is no need to modify their basic computational engines

to expand their applicability.

Regarding flexibility, special-purpose situational simulations are limited by the mathematical construct or

formalism used because of their lack of programmability. A general-purpose situational simulation, in

contrast, allows modelers to define their own formulations without any limitations other than the variables

supported by the overall model.

5

General-purpose situational simulations can promote collaborations in a synergistic manner not possible

through special-purpose situational simulations. General-purpose models can facilitate partnering among

institutions of higher education and between the academic community and the industry to leverage

resources and expertise in order to generate a richer educational environment for the learner. Educational

programs at different institutions of higher education exhibit different competencies. Sharing these

complementary competencies through simulation exercises can broaden the learner’s horizons.

Finally, a general-purpose situational simulation model can serve as a rich environment for the

development of a variety of research efforts. Because of its flexibility and broad application scope, a

general-purpose situational simulation paradigm can be used as a laboratory environment to perform

experiments and test hypothesis.

A GENERAL-PURPOSE SITUATIONAL SIMULATION ENVIRONMENT

FOR THE CONSTRUCTION DOMAIN

In order to explain the inner-workings of a general-purpose situational simulation environment for the

construction domain is necessary to first explore what such an environment means from the viewpoint of

participants and developers, to later define its conceptual foundation. For the purpose of this paper,

participants refer to the individuals who experience the simulated environment (regardless of their level of

expertise), while developers refer to those who design and build the environments.

Participant Viewpoint:

Participants in a general-purpose situational simulation environment of a construction management

process perform three basic activities: project awareness, project monitoring, and project management

(Fig. 1). Project awareness is a time unlimited task where participants familiarize themselves with the

project to be managed. They accomplish this by reviewing information from four different perspectives:

motivation, design, schedule, and budget. Some examples of the kind of specific information that each

6

one of these perspectives offers are illustrated in Fig. 1. The motivation perspective relates to the owner’s

reasons for pursuing the project. The design perspective conveys the specific details of the project. The

schedule perspective presents timing issues. Finally, the budget perspective familiarizes participants with

cost-related items in the project.

Project monitoring begins as soon as the participant initiates the construction phase of the project. From

this point forward the project advances in equal time intervals and information is provided about the

project’s performance at the end of every time interval. Pertinent data is compared to the expected values

found in the original plans as shown in Fig. 1. Typical project monitoring metrics such as the schedule

performance index, the cost performance index, and the productivity index among others, are presented to

the participant for analysis.

Project management is concomitant to project monitoring. In the absence of a situation (event),

participants have two choices: action or inaction. Inaction from the participant allows the simulation to

continue uninterruptedly. However, if the participant decides that there is an opportunity to improve the

performance of the process, then the simulation is paused in order to provide time to perform those

actions. When a situation arises, a participant is given information about its nature and severity and the

simulation pauses for a specified period of time to allow reaction to such a situation and minimize its

adverse consequences.

Finally, the new cycle section in Fig. 1 represents the iterative nature of the simulation as the clock

advances from one time interval to the next. Project monitoring and management continue throughout all

cycles in the simulation. The simulation ends when all activities in the project are finalized.

7

Developer Viewpoint:

Developers in a general-purpose situational simulation environment of a construction management

process perform four basic activities: project definition, situational design, situational definition, and

feedback cycle definition (Fig. 2). Project definition involves the selection of the project to be simulated

as well as the development of the information that participants will require during the awareness phase.

Situational design is at the core of a general-purpose situational simulation environment. Flexibility in

the design of situations is what makes the environment to be general rather than specific. Developers

must make decisions regarding scenarios, actions, and linkages. The scenario is the description of the

situation in its proper context, which requires a narrative and a countdown and may also benefit from

multimedia information. The narrative and multimedia add-ons explain the nature and severity of the

problem, while the countdown determines the time that a participant has to analyze the problem and react

to it. Actions determine the consequences of the situation on model variables, constraints, and

dependencies. These concepts are explained later in this paper. Suffice to say that actions translate the

fuzzy nature of a situation into specific effects on the project. For example, a situation such as a winter

storm may have as actions a 50% reduction of productivity for outdoor activities and a three-day delay in

material deliveries. Therefore, developers must establish cause and effect relationships between events

and actions. The model does not dictate these relationships in order to offer the greatest flexibility.

Developers can base these relationships on theories, empirical data, inventive heuristics, or expert advice

among other methods. The linkages relate to the kind of situation that the developer is creating:

dependent or independent. Dependent situations are directly linked to a specific activity, while

independent situations are not linked to any activity in particular. For example, problems related to the

concrete pouring of a foundation wall are clearly restricted to that activity. On the other hand, a labor

strike is likely to affect all activities. As illustrated in Fig. 2, developers can contribute their independent

situations to a situational library.

8

Situational definition is the process of selecting the situations that will affect a particular simulation.

These situations can come from both the situational design phase or from the situational library created by

the community of developers. During the situational definition phase, developers also specify the

relations among situations regarding their potential juxtaposition to maintain logical integrity. For

example, the situations described previously regarding a winter storm and problems with the pouring of a

foundation wall may not be temporally compatible as it may be illogic to have a problem arising from the

pouring of concrete when concrete cannot be poured at all due to poor weather conditions.

Developers also need to specify the feedback cycle. The feedback cycle is defined as the timeliness of

information given to participants. A simulation may offer real-time data or delayed data or a combination

of both. Defining the feedback cycle also includes the decision regarding what information is available

to the participant.

Conceptual Foundation:

The analysis of the viewpoints of participants and developers served as the basis for the conceptualization

of a general-purpose situational simulation environment (Fig. 3). This conceptualization includes three

interrelated models: the process model, the product model, and the information model.

The objective of the process model is to represent the construction process through a formal set of

entities. The process model is defined by constraints, dependencies, attributes, and events. Constraints

are limitations to the process given by nomological, definitional, or constitutive principles. Nomological

constraints are non-negotiable limitations that must be satisfied because they are dictated by natural law.

Two instances are space and time. For example, in the process model, two materials cannot occupy the

same space at the same time nor the total amount of materials stored at the site can exceed the available

space. Definitional constraints are limitations imposed by mathematical relationships. Two instances are

the polynomial order of the equations and the deterministic/stochastic nature of the variables. Finally,

9

constitutive constraints are limitations imposed on the process model by choice. Two instances are

productivity and materials. Productivity is represented in the process model as dollars per unit of time,

rather than squared feet, cubic yard, or any other production metrics per unit of time. This limitation is

imposed to provide a single unit to measure the variable and thus facilitate the application of events that

impact the productivity of a variety of activities. Materials, is another variable for which a limitation is

specified. The number of different materials in a typical construction project could run into the

thousands. In order to reduce the data storage requirements of the process models, materials are classified

into two categories: driving and non-driving. An activity-based material tracking system for driving

materials is supported in the process model. Driving materials are defined as the biggest cost drivers in

an activity. This self-imposed limitation on the process model significantly reduces the number of

materials to be tracked, as it is often the case that only a handful of materials comprise most of the

material costs of an activity even if several dozens are required. Non-driving materials are bundled into

one variable and are immune to changes in prices.

Dependencies are relationships among variables given by technical, financial, and resource enslavements.

Technical dependencies are given by the construction schedule and represent the hard and soft logic

sequencing of a project. Financial dependencies are dictated by the cost relationships among variables.

For example, indirect costs are dependent on the duration of a project and the supply chain structure

implemented. Resource dependencies are determined by the relationships among the different variables

and resources such as materials, labor, and equipment. As an illustration, the rate of consumption of

resources by an activity is related to its scheduled duration. If the activity duration is to be compressed,

the rate of resource consumption increases.

Attributes are the specific characteristics that identify a variable. For example, a material may have

attributes such as quantity, cost, procurement date, equipment required, and parent trade among others.

Labor may have attributes such as crew size, wages, benefits, mark-ups, category, and efficiency.

10

Events are particular occurrences of situations. For example, an event could consist of the receipt of a test

report from a concrete pour of several columns, in which the experimental results from a 3-day

compression test are 25% below the expected strength. The participant, as decision-maker, can disregard

the results, order new tests, wait for the 7-day compression tests, demolish and re-construct the columns,

and so on. The specific action taken by the participant, as well as its cost, calculated through

dependencies and constraints, determines the impact the decision has on the original schedule, and other

relevant factors.

The product model is a representation of the physical facility and is defined by its scope, granularity, and

interactivity. The scope relates to the percentage of the actual facility that needs to be represented by the

product model. This decision is dependent on the information and process models needs. For example,

some situational simulations may focus only on a few activities rather than on an entire project. When

this is the case, there is no need to model the entire physical facility, as a model of the physical structure

associated with the preceding activities and those required by the simulation exercise should suffice. In

addition, the scope of the product model can also be limited by proper restriction of the interactivity of the

model. There is no need to model those aspects of the physical structure that are not going to be

experienced by the participant. In essence, the same principles that apply to the design of movie sets, also

apply to the definition of the product model: build/model only those items that the viewer/participant is

going to be exposed to.

Granularity is related to the level of detail on the model of the physical facility. The granularity of a

product model is intrinsically associated to the project schedule in order to support 4D visualizations of

the process. However, granularity is also linked to the situations as different scenarios may require

different levels of detail in the product model. For example, a situational simulation developed to expose

participants to the 1981 Kansas City’s Hyatt Regency Hotel disaster (Sweet 1999) should include fully

developed details of the steel connections for the second and fourth floor walkways according to both the

11

original design and the proposed modification. This level of detail would be of the essence for the

success of such a simulation. However, if a similar facility is modeled for a simulation without events

related to the steel connections, then the product model does not have to provide such level of detail and

details about the connections of steel members could be omitted all together from the model.

Finally, interactivity relates to the ability of the model to be customized to better serve the participant.

The interactivity of the product model is correlated to the scope and the level of granularity required. The

technology selected to present the product model to the participant is also a limiting factor of the degree

of interactivity. For example, immerse virtual reality models are more interactive than non-immerse ones,

and these in turn are more interactive than non-virtual reality models.

The information model is made up of the context, the situational scenarios, and the execution plan. The

context provides the participant with information related to the construction project including scope

definition and business plan or project motivation. It also provides data about the site in which the project

will be erected including information such as local availability of resources (labor, materials, equipment),

and local regulations. This context information offers the participant a general understanding of the

project goals and restraints.

Situational scenarios provide the participant with specific information about managerial, technical, and

external events. An important factor that differentiates situational simulations from games is reality of

function. Reality of function occurs when participants accept their roles and fulfill their responsibilities

seriously and to the best of their ability. In order to accomplish this, a situational simulation must provide

sufficient information so that participants can behave in a professional manner. The objective of the

scenarios is to convey the magnitude, severity, and timeless of the problem or opportunity as well as all

the relevant facts to encourage an analytical rather than a heuristic response.

12

Finally, the execution plan introduces participants to the original resource-loaded schedule, cost estimate,

site layout, and supply chain arrangements. Participants are free to deviate from the original plan while

managing the simulated construction process if they believe that the process can be improved. However,

the original plan serves as a benchmark to evaluate the appropriateness of their decisions. Deviations

from the original plan can also occur when events happen and participants are expected to adjust the

different parameters under their control to go back to the original or the improved plan.

IMPLEMENTING THE ENVIRONMENT: THE VIRTUAL COACH

We have argued that programmability is one of the advantages of a general-purpose situational simulation

environment. However, when examining the developer viewpoint we did not mention anything regarding

the ability of developers to change the underlined relationships in the environment such as the formalism

used to determine remaining duration of activities. This omission was intentional, as we want to maintain

the conceptualization and implementation of the environment as two independent constructs. Every time

that we use the word “simulation,” a picture of a computer system develops in our minds. However,

simulation is not a synonymous of computing as simulated environment can be created without using

computers. The activities, models, and relationships depicted in Figs. 1, 2, and 3 can be performed and

implemented without using a computer system to maintain the script and represent, therefore, the

conceptual foundation on top of which different computing systems can be developed to automate the

environment.

The Virtual Coach is an example of such a computer system developed by the writers. It represents the

migration from the conceptual modeling to the implementation of a general-purpose situational simulation

environment.

13

The Simulation Engines

The Virtual Coach is a web-based system made up of three computational engines: the emulation engine,

the visualization engine, and the development engine. The emulation engine is responsible for

performing all mathematical calculations and storing data. The visualization engine is in charge of

reading data and presenting it to the participant in a visual format. The development engine is responsible

for providing a developer environment to facilitate the creation of situational simulations to be run on the

Virtual Coach.

The Emulation Engine

The Emulation Engine is the core of the Virtual Coach and it is based on a theoretical abstraction of the

construction process which provides the blue print for implementation. In the Emulation Engine, the

activity network diagram is stored as a directed graph, in which vertexes represent activities and edges

represent constraints. The direction of the graph provides the precedence order of the activities. Activities

connected by edges are constrained by finish-to-start, start-to-finish, finish-to-finish and start-to-start

relationships. Constraints are also defined by resource requirements. Successful completion of activities

depends on the availability of specific quantities of labor, equipment and materials. In the absence of the

necessary resources, activities cannot be successfully completed. Resource constraints and precedence

constraints are activity and project specific and provided to the participant.

In simulating a construction project, the Emulation Engine requires access to all the project specific

resource and precedence constraints. This information is stored in the “As-Planned” database. The

schema defining the database (Rojas and Mukherjee 2002) stores material, labor and equipment

information for unique time-activity elements. A time-activity element is defined as the section of any

activity across the smallest unit of time represented in the simulation. The smallest unit of time

represented is usually a day. Hence, the database stores information about the material, labor and

equipment requirements of activities over each day during the duration of an activity. The information is

14

stored in a relational database, which is dynamically queried during the simulation to access activity

specific resource requirements that create the corresponding resource constraints. Precedence constraints

are also stored in the “As-Planned” database. This information is completely shipped from the database to

the visualization engine before the simulation starts and is available to participants during the project

awareness phase.

During the simulated construction process, precedence and resource constraints may be violated by

various events, which can occur in the construction environment. Events are causal in nature and relate to

the construction environment. They directly result in disturbing or violating precedence or resource

constraints. For instance, a day of bad weather could create delays in all outdoor activities. The link

between the bad weather event and the delay is causal, while the result of the delay has cascading effects

on the whole activity network further delaying future activities bound by precedence constraints.

Similarly, there is a direct causal link between the delivery of a material being delayed and the

unavailability of the material for the specific activity, which in turn translates to a resource constraint

violation. The causal links between the effects of events and their occurrences, and the conditions, which

lead to their occurrences, have been formally described using the syntax of First Order Logic and formal

axiomatic semantics (Russell and Norvig 2002), which can be used to represent and logically reason

about events and constraint violations in the simulation environment. Knowledge, defining a range of

events that may occur in the environment is axiomatically represented in a knowledge base, which is

queried as the simulation proceeds. The reasoning mechanism is part of the process model.

Information in the simulation environment is represented by a set of variables, each of which takes up

different attributes of the aspects of the environments they describe. The situational simulation

environment is a temporally dynamic environment and all changes in the environment are reflected by

changes in the values of the variables. The variables can be classified into global variables, which

specifically define the environment; and activity specific variables, which describe precedence

15

relationships, related to the activity, accumulated delays, available float, and the resource availabilities

pertinent to specific activities as the project progresses. The values of activity specific variables are

affected by constraint violations and participant intervention through re-allocation and/or redefinition of

resources. As the simulation proceeds, activity specific variables in the simulation tend to become

different from activity specific variables in the “As-Planned” database. The differences reflect events that

occurred in the environment and possible corrective measures that were taken by the participant to satisfy

violated constraints.

From the point of view of the mathematical model (Rojas and Mukherjee 2003a), which is a constituent

of the conceptual process model, the activity specific variables are the independent variables. The

mathematical model is a set of functions, which maps independent variables to dependent variables such

as direct and indirect cost, production rates, percentage completion of work and projected remaining

activity durations at any point of time during the project. During the simulation of the project, there will

always be two kinds of dependent variables that can be calculated. The first set is calculated from the

static “As-Planned” data and reflects how the project should have been ideally implemented in terms of

cost and time. The second set is calculated from the dynamic activity specific simulation variables, which

register the “As-Built” information. The differences between the two sets of dependent variables

calculated during the progress of the project, provides participants with indicators of their success during

project implementation.

The construction management process can be divided into two different phases. The first phase can be

modeled as a planning and constraint satisfaction problem, during which the most optimal plan, in terms

of time and cost, is developed, keeping in mind defined project specific precedence and resource

constraints. The solution to this problem results in the “As-Planned” program. The second phase is project

implementation during which the construction manager has to deal with events and respond to constraint

violations by taking corrective measures. The current implementation of the Virtual Coach simulates the

16

second phase assuming awareness of the first phase. The emphasis is on simulating the construction

environment and the generation of events during the implementation phase while referring to the “As-

Planned” schedule stored in the information model. Based on information derived from the knowledge

base, the Emulation Engine simulates events, which result in constraint violations. The constraint

violations translate to situational scenarios. Participant skills are tested by how well they can take

corrective measures to satisfy violated constraints.

The Visualization Engine

The Emulation Engine describes a logical and mathematical abstraction of the construction environment,

which is used to create the simulation. However, the simulation environment remains incomplete without

a virtual rendition of the reality that is being simulated. This calls for an interface to allow the participant

to seamlessly interact with the environment. Participation in the environment translates to participants

having limited access to control and alter variables, which describe the simulation environment.

Participant decisions are enacted through their control of specific variables. The phrase “limited access”

has been used, because, as with reality, participants cannot control every aspect of the environment. For

instance, the weather is beyond human control. However, participants can reallocate resources or procure

alternate resources. The simulation provides them access only to activity specific variables, which

describe resource availability. For participants to be able to make informed decisions, it is very important

that they have access to information about the environment. This information includes an awareness of

the environment as well as an indicator to their performance in implementing the project. While values of

global and activity specific variables provide information about the former, a comparison of dependent

variables calculated from static “As-Planned” data and dynamic “As-Built” data provides feedback on the

later. The interface is the medium, which provides this information to the participant.

The best way to present information concisely and precisely is to present it in visual format. The function

of the Visualization Engine is to visualize information pertinent to the environment. Information in the

17

environment has been appropriately classified based on information semantics specific to the simulation

environment (Rojas and Mukherjee 2003b). Each information module is mapped onto appropriate visual

modules like graphs, images, media files, AutoCAD drawings and 3D models. The Visualization Engine

receives consistent information and depending on the nature of the information, calls upon the

corresponding visualization mechanism. The development of the Visualization Engine allows a

decoupling between the visualization mechanism and the project being simulated. The mechanism is

scalable and reusable for visualizing simulation information, independent of the simulated construction

project, as long as the information is defined within the semantics of the simulation.

The Development Engine

The philosophy behind developing a general-purpose simulation is to allow developers to “program” the

environment conveniently and create situational simulations relevant to their area of expertise without

having to deal with the details of the system. The Emulation Engine and the Visualization Engine are built

on abstractions, which provide a framework for a general purpose simulation, while the Development

Engine provides an interface that assists developers to design situational simulations that suit their

purposes. Through the Development Engine the developer inputs the “As-Planned” database, the

knowledge base and the media and design files relevant to the simulated environment.

The Distributed Architecture

The Virtual Coach is implemented over a client-server architecture. The web-based implementation of the

Virtual Coach justifies the distributed architecture. There is a centrally located server, which hosts the

components of the information model; the “As-Planned” database and the knowledge base. Participants

can be located at different points on the web. They are required to install the Emulation and Visualization

engines at their locations and set-up a master-slave relationship with the server. The Emulation Engine

does all the logical and mathematical processing, which effectively runs the simulation. This allows

18

transferring the processing load of the simulation from the central server to the clients. Multiple clients

can access the server and run the simulation from their own locations.

Information regarding the simulation is accessed by the client from the server. The query processing

technique used by the client is a hybrid one. While activity precedence information is shipped entirely at

the beginning of the simulation, activity resource requirements are queried dynamically from time to time

during the progress of the simulation. This calls for maintaining logical and temporal consistency of

queried data that is being applied to the simulation. Maintaining logical consistency of queried

information with respect to simulation and server time across multiple locations has been discussed in

detail in Rojas and Mukherjee (2003c).

BUILDING THE SYSTEM

The Virtual Coach has been implemented in Sun Java because of its inter-operability and sophisticated

object oriented scheme. Java’s ability to implement interfaces and extend classes provides great

flexibility in developing and implementing an extensible framework. Two Open Source Java packages

were also used to build the system. One archive provided various data structures like maps, vectors,

directed graphs and allowed simple manipulations and searches within such structures (such as a simple

depth first search in a directed acyclic graph). The other archive was used to plot and update graphs of

data being generated during the simulation process. Slight changes in the code had to be made to suit out

specific needs.

The current version of the system is very limited in its implementation and serves the purpose of being a

pilot. The simulation environment takes into account limited variables and a limited number of events.

Also, the participant interactivity is limited to resource allocation and purchasing/hiring new resources.

Future versions will strive to add more environment variables and represent the environment in greater

detail. Future collaboration with the industry will enhance the encoding of realistic scenarios and events

19

within the existing framework. The current implementation simply validates the framework and provides

a platform to do preliminary studies pertaining to how students react to such a system. Future versions

will also develop a significantly more sophisticated user interface. The current interface only provides the

basic elements required to run the simulation. Future information visualization will involve multimedia

contextual information, 4D graphics of the project site (time and space) and also allow the participant to

dynamically schedule the simulated project. Despite its current limitation, the pilot includes more then

7,000 lines of code. This Open Source software can be obtained by contacting the authors.

The pilot has a client-server relationship with a PostgreSQL database that contains information about the

project that is being simulated. The Emulation Engine reads the “As-Planned” cost and schedule

information and the various event parameters (event densities, event probabilities, event durations, etc.)

from the database server during the pre-simulation phase. This information provides the user with a basic

understanding of the project before the simulation starts (Fig.4). As the simulation proceeds, the

Emulation Engine documents all user decisions (what decisions they take within the environment) and

user interactions (time stamped record of mouse clicks) within the system. This information also gets

written to the database server as the simulation proceeds and can be used later for data mining purposes.

The pilot runs two main parallel threads. The main thread runs the Emulation Engine and steps the

simulation through each day/week of the simulation and carries out all the relevant calculations and

logical inferences about the simulated project. The second thread runs the Visualization Engine. The two

threads are dependent on each other. Information processed in the main thread dispatches a message to

the visualization thread triggering it to update its information panels. Once the information panels have

been updated and the user has completed input, the visualization thread passes back control to the main

thread, which then proceeds to update the environment to reflect the user’s decisions.

20

The main thread maintains temporal and logical consistency of variables in the simulation and keeps it

updated to accurately reflect user interactions. The entire simulation environment is coded in terms of

discrete and continuous variables, which define specific aspects of the environment. An example of a

discrete variable is weather, which can take discrete values of “Sunny”, “Snowy” and “Rainy”. Cost and

productivity variables are represented as continuous variables and can take up values from the set of real

numbers. The main thread infers possible future events based on the current situation within the

simulation environment (Mukherjee and Rojas 2003) and then generates the probabilities of such events

occurring based on previous occurrences and other conditional dependencies. The inferred events are

scheduled and future values of the environment variables are updated to reflect the effects of current

events. The main thread also calculates the remaining duration of and work remaining on each activity in

the simulated project at the end of each day/week. It also updates project records of direct and indirect

costs of the simulated project. This information is periodically passed onto the visualization thread, which

in turn updates the visual interface. Finally, the main thread writes time stamped information to the

database for future data mining purposes.

Appropriate information visualization and user interactivity are critical to the success of the Emulation

Engine. Figs. 4, 5, 6 and 7 provide screenshots of the pilot deployment of the system. Fig. 4 shows the

pre-simulation briefing screen, which informs the participant of the particulars of the simulation

environment immediately before the simulation starts off. Fig. 5 shows the resource allocation screen,

which informs the participant of the total available resources in the environment and the total resource

requirements specific to each ongoing activity in the simulation. Each activity panel also has a graph

showing the “As-Planned” versus the “As-Built” rate of work completion. The participant is allowed to

assign more or less than the planned requirements depending on availability to accelerate or decelerate the

project. In the absence of the necessary resources, the participant is also allowed to hire more labor and

purchase more material at a premium price (Fig. 6). Finally, Fig. 7 illustrates the daily progress report.

Participants can view the current state of progress and compare it to the “As-Planned” schedule. They can

21

also keep track of direct costs, indirect costs and space requirements by following the graphics at the

lower left hand corner of the screen. The lower right hand corner of the screen allows participants to

monitor the values of discrete and continuous environment variables.

CONCLUSIONS

This paper has introduced the conceptual framework and initial pilot implementation of a general-purpose

situational simulation environment for construction education. The emphasis has been on its Emulation

Engine. Future research will focus on the refining of the Visualization Engine and the development of the

Development Engine. Furthermore, the situational simulation environment described in this paper is

circumscribed to the construction phase of a project and a project manager who is managing all activities.

This environment, however, could be expanded in the future both horizontally and vertically to

encompass a broader scope.

Downstream vertical expansion could be accomplished by giving control of subset of activities to other

participants who can play the role of subcontractors in a project. Upstream vertical expansion could be

accomplished by collecting information from several projects and providing that information to a

participant or group of participants to act as the CEO or Board of Directors of a construction company

with the authority to coordinate decisions with the different project managers. Front-end horizontal

expansion could be implemented by relinquishing some of the activities that developers perform in the

project definition phase (Fig. 2) to the participant. This would allow the participant to perform project

planning activities in addition to project management activities. Back-end horizontal expansion could be

achieved by running concatenated simulations. In other words, running a situational simulation inside

another situational simulation would allow for the simulation of facility management activities.

Finally, general-purpose situational simulations are tools that construction educators may use to convey,

in a dynamic manner, the complex relationships and trade-offs present in most construction projects.

22

They may be a welcome addition to the engineering educator’s toolkit and serve their purpose alongside

other complementary pedagogical approaches.

REFERENCES: AbouRizk, S. (1993). “Stochastic simulations of construction bidding and project management,”

Microcomputers in Civil Engineering, 8, 343-353.

AbouRizk, S. and Sawhney, A. (1994). “Simulation and gaming in construction engineering education,”

ASEE/C2E2/C2EI Conference, Edmonton, Alberta.

Barab, S.A., Hay, K.E., Barnett, M. and Squire, K. (2001). “Constructing virtual worlds: tracing the

historical development of learner practices,” Cognition and Instruction, 19 (1), 47-94.

Bertz, M. and Baker, N.C. (1996). “CELL – a vertically integrated learning resource,” Proceedings of the

Third Congress on Computing in Civil Engineering, ASCE, Anaheim, 348-354.

Brown, J.S., Collins, A., and Duguid, P. (1989). “Situated cognition and the culture of learning,”

Educational Researcher, 18 (1), 32-42.

Chi, M., Bassok, M., Lewis, M., Reimann, P., and Glaser, R. (1989) “Self-explanations: how students

study and use examples in learning to solve problems,” Cognitive Science, 13, 145-182.

Chinowsly and Vanegas (1996). “Combining practice and theory in construction education curricula,”

1996 ASEE Annual Conference Proceedings

23

Echeverry, D. (1996). “Mulimedia-based instruction of building construction,” Proceedings of the Third

Congress on Computing in Civil Engineering, ASCE, Anaheim, 972-977.

Fruchter, R. (1997). “The A/E/C virtual atelier: experience and future directions,” Proceedings of the

Second Congress of Computing in Civil Engineering, ASCE, Atlanta, 441-448.

Halpin, D. and Woodhead, R. (1970). “A Computerized Construction Management Game.” Department

of Civil Engineering, University of Illinois, Urbana Champagne.

Jaafari, A., Manivong, K., Chaaya, M. (2001). “VIRCON: interactive system for teaching construction

management,” Journal of Construction Engineering and Management, 127 (1), 66-75.

McCabe, B., Ching, K.S., and Savio, R. (2000). “STRATEGY: a construction simulation environment,”

Proceedings of Construction Congress VI, 115-120.

Mukherjee, A. and Rojas, E (2003) “Reasoning about actions and events in situational simulations.”

Proceedings of the 2003 Winter Simulation Conference (SIGSIM), New Orleans, Louisiana.

Ndekugri, I. and Lansley, P. (1992). “Role of simulation in construction management.” Building

Research and Information. 20 (2), 109-115.

Russell, S. J. and Norvig, P. (2002). Artificial intelligence: a modern approach. Prentice Hall; 2nd edition.

NSF (1995). “Restructuring engineering education: a focus on change,” Report of the 1994 NSF

Workshop on Engineering Education, Division of Undergraduate Education, Directorate for Education

and Human Resources, National Science Foundation, Washington D.C.

24

Pennell, R., Durham, M., Ozog, C., and Spark, A. (1997). “Writing in context: situated learning on the

web,” Proceedings of the 14th Annual ASCILITE Conference, Perth,WA, 463-469.

Rojas, E. and Mukherjee, A. (2002) "Data modeling for the virtual coach." Proceedings of the ASCE EG-

ICE Joint Workshop on Information Technology in Civil Engineering, ASCE, 308-317.

Rojas, E and Mukherjee, A. (2003a) "Modeling the construction management process to support

situational simulations." Journal of Computing in Civil Engineering, ASCE, 14 (4), 273-280.

Rojas, E and Mukherjee, A. (2003b) “Visualizing situational simulation information” 2003 Construction

Congress, ASCE.

Rojas, E. and Mukherjee, A. (2003c) “Implementing situational simulations through distributed

databases.” 2003 Construction Congress, ASCE.

Sawhney, A., Mund, A., and Koczenasz, J. (2001). “Internet-based interactive construction management

learning system,” Journal of Construction Education, 6 (3), 124-138.

Sweet, J. (1999). “Legal aspects of architecture, engineering and the construction process.” Sixth Edition.

Brooks-Cole ITP, New York.

25

List of Figures:

Fig.1: Participant Viewpoint

Fig.2: Developer Viewpoint

Fig.3: Conceptual Foundation

Fig.4: Pre-Simulation Briefing Screen

Fig.5: Resource Allocation Screen

Fig.6: Material Purchase Screen

Fig.7: Day Ending Report

26

NEW CYCLE

PAUSE

PAUSE

PROJECTMANAGEMENT

4DCAD

CPM

Gantt

PROJECTAWARNESS

DirectCosts Cash

Flow

Contin-gency

IndirectCosts

Values

Goals

Mission

Team

Budget Sched

ule

DesignMoti

vatio

n

Civil

Arch.

3DCAD

Anima-tions Opportunity

Situation

Inaction

Action

Reaction

PROJECTMONITORING

Comparison(Actual vs Planned)

Cost

Time

4D CAD

Market

Weather

Resources7 56

121110

8 4

21

9 3

27

PROJECT DEFINITION SITUATIONAL DESIGN

2D CAD Model

Schedule

Linkage

Scenario

ActionsActivity-basedBudget

Motivation

Market Data

Activity-based3D CAD Model

Cash Flow Animations

Narrative

Multimedia

Countdown

Variables

Constraints

Dependencies

Independent

Dependent

SITUATIONALLIBRARY

SITUATIONALDEFINITION

FEEDBACKCYCLE

DEFINITION

28

VisualizationMechanism

Constraints

Nomological

Definitional

Constitutive

Scope

ContextManagerial

Technical

External

SituationalScenarios

Process Model

Information Model

Product Model

Execution Plan

Cost Estimate ScheduleSupply ChainSite Layout

Attributes

Granularity

Interactivity

Dependencies

Technical

Financial

Resource

Events

Space

Productivity

Time

Materials

Polynomial OrderDeterministic/Stochastic

MarketsNature

PARTICIPANT

ProductFeedback

ProcessFeedback

29

30

31

32