Current construction management techniques center around the ‘iron triangle’ of scope/quality, schedule, and resource use, with the common understanding that only two of these three aspects can be optimized in a project. On the other hand, the Project Production Institute (PPI) advocates an Operations Science-based approach to managing projects using five levers invalidating the iron triangle. Those levers are product design, process design, capacity, inventory, and variability. Current methods available for analyzing these levers include Building Information Modeling (BIM) used for product design in the built environment, and operation science concepts and techniques like Little’s Law and Discrete Event Simulation (DES) for the other four levers.
However, there is a gap in knowledge in integrating the analysis of all these levers together to optimize construction production systems due largely to a lack of integration between their respective modeling methodologies. Thus, this paper presents a method to integrate DES modeling and analysis with BIM in order to enable information exchange and to analyze and understand the interdependencies between levers through an integrated product-process modeling approach towards enable optimization of construction production. For instance, the (variable) duration for a crane (capacity) to place (process) a module (inventory) in its place will depend on the location of that module as specified by the BIM model (product design). Each of the five levers can be controlled in our framework to understand impact on other levers and production. Further, our framework enables the reuse of DES models for different projects by automating data input from BIM models specific to the new projects – thus easing adoption of DES on construction projects.
Keywords: Discrete Event Simulation; Building Information Modeling; Product-Process Integration
Joseph Louis is an Associate Professor in the School of Civil and Construction Engineering at Oregon State University. He received his Ph.D. degree and his M.Sc. in Civil Engineering from Purdue University in 2016 and 2010, respectively. He has created the ConStrobe Simulation Engine, and applies it to simulate and analyze various operations in the ...
Construction projects are rife with time and cost overruns despite tremendous advances in construction equipment and supporting technologies to aid with their planning, monitoring, and control. This is especially evident when comparing construction productivity over the years with non-farm industry productivity – which shows a stagnation in the former relative to great gains made in other industries [1,2]. Some of these performance issues could be attributed to the inherent characteristics of construction projects – a construction project being a temporary endeavor with multiple collaborators who have not worked together before; uniqueness of construction products preventing standardization and automation; and uncertainties inherent in logistics and planning. Still, at least some of these performance issues could be traced to the way construction projects are managed – specifically how there is a complete lack of integration between the product of a project’s endeavor and the production process need to realize that product. Zabelle [3] discusses these gaps in current management practice quite extensively and notes that the separation of management activities (such as risk management, and schedule and cost control) are currently quite separate from the actual production of the work in the field. Zabelle advocates for more integration of process analysis underpinned with an Operations Science technical framework to plan and control projects.
In a similar vein, the Project Production Institute (PPI) [4] argues that more process-related information needs to be considered to analyze projects beyond the conventional project management view that only two out of the three elements of the iron triangle – scope/quality, schedule, and resource use – can be simultaneously improved on construction projects. They define five production-based levers of product design, process design, capacity, inventory, and variability “the technical basis to map, model, analyze, optimize, control, and improve project production system performance” [4].
While several aspects of Operations Science – such as Little’s Law and queueing theory –enable analysis of process- and resource-related levers (excluding product design), this paper focuses on discrete event simulation (DES) because it provides the greatest accuracy and flexibility in modeling the construction production systems of interest [5]. The most analogous modeling method that is used for the remaining lever – product design – is Building Information Modeling (BIM) currently used in the built environment . Figure 1 maps the production levers to specific methods and tools that support their analysis.
From Figure 1, it can be seen that while each of the levers has a suitable modeling method (or significant feature of a modeling method) to support its analysis, there is no integration between the modeling methods of BIM and DES itself, which precludes modeling the impact of all five levers acting together on construction production performance. Efforts to integrate these aspects of analysis include Computer Aided Production Engineering (CAPE) [6] and Concurrent Digital Engineering [7]. This paper adds to these efforts by focusing specifically on integrating modeling and analysis capabilities of BIM with DES to support holistic analysis of construction production systems. The literature review presents an overview of the development of DES for construction to delineate its limitations that hinder its use on real-world projects. This will be following by a description of the lead author’s DES engine and the framework that enables it to integrate with BIM models. The conclusions will be presented that highlight ongoing efforts to demonstrate this framework for various construction and other similar projects.
Academic research in construction has resulted in very powerful tools that could enable process analysis tailored for the unique nature of construction operations. Foremost among these is discrete event simulation (DES), which is a simulation method that advances through discrete jumps in time, and which has been noted to be the most appropriate method for modeling the field production process in construction. Martinez and Ioannou [8] note that the activity scanning (AS) simulation strategy for DES is preferable than process interaction (PI) for modeling construction operations based on the criteria of application breadth and flexibility of the simulation strategy. Their implementation of a DES software application, called STROBOSCOPE [9] uses modeling elements from an earlier construction DES engine called CYCLONE [10] and has been used to model and analyze a broad range of construction activities in great details to provide insights that would be impossible to gain with other scheduling or spreadsheet-based analysis. Another significant simulation system developed for construction is the Simphony framework [11], that enables developers to create special-purpose templates for various construction operations, including the provision of a CYCLONE template that enables general-purpose modeling. Most notably, AbouRizk [12] has extended the capabilities of Simphony to create the Simphony.NET framework, which enables individual simulation models to be part of a larger distributed federation of simulation, as defined by the IEEE1516 HLA framework. It is anticipated that this development will allow DES models to analyze even more complex construction operations. These and other similar DES modeling tools have been used previously to analyze a broad range of construction operations including tunnel boring [13], earthmoving [14], pipe-spool module assembly [15], modular construction [16], and disaster recovery [17], building construction trades [18], and asphalt paving operations [19], and other capital infrastructure projects [20].
Despite the existence of such sophisticated simulation methods with such a broad range of application, they have not been adopted by industry, thereby foregoing the operational analysis that could and should supplement project-based analysis. This has been widely studied and reported on in literature [21,22,23], which have identified several obstacles that hinder adoption of DES by industry including characteristics of construction operations itself, industry culture and focus, preparedness and knowledge of construction workforce regarding simulation, and the limitations of simulation tools themselves in providing outputs of interest to practitioners.
This paper particularly focuses on overcoming the last two types of obstacles which focus more on the capabilities and ease of use of the simulation tools themselves. The thinking here is that if DES models can be integrated into tools that are already well established in industry (like BIM) and minimal effort is needed to obtain production performance measures from DES that are tailored to specific projects, it can find greater adoption by industry. Towards this end, this paper provides a means of integrating process analysis enabled by DES with product design (represented by BIM). This integrated framework also provides the last remaining link between the product design lever and other levers to enable a holistic analysis of construction projects from a production perspective. This framework is implemented in the ConStrobe discrete event simulation engine and software that is described in the next section.
ConStrobe – Construction Operations Simulation for Time and Resource-Based Evaluations – is a discrete event simulation engine and software application that is developed for construction simulation. It is inspired by the STROBOSCOPE language [9], which itself uses the modeling elements introduced by CYCLONE [10], but has been developed independently of these efforts by the lead author, Dr. Joseph Louis. ConStrobe is a general-purpose simulation engine that implements the three-phase activity scanning simulation strategy for processing operation models which are represented as activity cycle diagrams (ACDs). The details of the three-phase AS simulation processing algorithm can be found in [9]. The elements that make up activity cycle diagrams are described in Table 1.
| ACD Element Symbol | Description |
|---|---|
 | Queues are nodes that hold idle resources of a certain type until the resource is drawn away by an activity (specifically a Combi activity). Resources in queues are considered to be in an idle state and waiting to perform an activity. Queues can only precede Combis but can be preceded by any other node (except a Queue). |
 | A Combi is a type of activity that can start only when certain conditions are met, as opposed to starting immediately upon finishing its preceding activity. A Combi is associated with duration and represents tasks in the operation that are subjected to multiple constraints. A Combi can only be preceded by a Queue but can precede any other node (except a Combi). |
 | A Normal is a type of activity that starts as soon as its preceding activity concludes. A Normal is associated with a duration and represents tasks in the operation that are not subjected to multiple constraints. A Normal can only be preceded by any Activity (Combi or Normal) or Fork, but not a Queue. A Normal can precede any other node (except a Combi). |
 | A Fork is a routing element that can route a specific type of resource probabilistically through its outgoing branches based on their proportional strength. It is considered to be an auxiliary element and can precede any node in an ACD except for a Combi. |
 | A Consolidator is an element that collects resources of any type until a specific condition is met, upon which it releases all collected resources through their respective outgoing links. These can precede any node other than a Combi and succeed any element other than a Queue. |
 | Assembler and Disassembler are auxiliary elements that are used to combine resources into a specific characterized resource and to separate them when needed in the model. These can precede any node other than a Combi and succeed any element other than a Queue. |
 | Links are used to connect the nodes to each other to create an ACD networks. These provide channels for the flow of resources between nodes and can only provide this capability for their assigned resource type. Links can be classified as a Draw Link (if it connects a Queue to a Combi) Release Link (if it emanates from an Activity). |
Figure 2 provides a screenshot of the ConStrobe application graphical user interface, which is implemented using the Qt API with the C++ programming language.
The GUI provides the means of both building the ACD using a drag and drop interface, and running the ACD to obtain statistical simulation results. The following numbered elements can be seen in Figure 2:
1 ACD Area: This is the main portion of the GUI where users drag and drop modeling elements to create the ACD model of the operation. The ACD in the figure is for an earthmoving operation.
2. ACD Stencil: This area contains the modeling elements that can be used to build the ACD.
3. ACD Element Properties: This area provides the means of viewing and editing the selected element’s attributes. In this case, the selected element is the Load Combi – outlined in blue.
4. Simulation Controls: These controls allow the user to start, pause, and stop simulation.
5. View Controls: These controls allow the user to control the appearance of the ACD model.
6. Parameters, Resources, and Code: These elements enable users to set parameters for the simulation, define resource types and properties, and write code to enhance ACD behavior.
The desired product-process integration is achieved through the provision of a library – pyconstrobe – which provides the means of automating ConStrobe through the Python programming language. While ConStrobe can be used independently as a simulation engine, the pyconstrobe library now enables Python programs to launch ConStrobe, open a specific ConStrobe file, set attributes of various modeling elements inside the model, and then run the simulation using the updated attributes. Furthermore, while the model itself is running, the ConStrobe model can request information from the Python program that launched it using the GET() function within ConStrobe and also use the POST() function to publish data to the Python program. This paper will not delve into the details of syntax and usage of these features either on the Python or the ConStrobe file – and these details can be obtained from the ConStrobe webpage. However, these two sets of capabilities enable the constant communication of the process model with a Python program and form the basis of the integration of product with process.
This integration itself is obtained when the same Python program that launches and automates ConStrobe also reads BIM models using an IFC file reader for Python called IFCOpenShell. This enables the Python program to obtain all the product-related information on the same platform that enables communication with the process model and can thus provide an appropriate response to a query from ConStrobe using product-related information. This workflow is illustrated in Figure 3.
The framework from Figure 3 is currently being used to develop examples demonstrating BIM-DES integration for a modular construction project for high-density housing. The product-process integration framework aims to simulate the time taken to move modules into place by various sizes of cranes based on the location of the specific module in the building. Thus, here we are analyzing on-site capacity (crane), inventory (module), product design (location of module in the building), process design (location of crane and module drop-off location etc., and variability (uncertainty in activity durations).
Figure 4 shows the BIM model of the housing project, which is modeled to reflect the location of each separate module that will need to be placed. Figure 5 shows a visual of the construction site along with the following key resources: (a) laydown yard that serves as buffer between offsite modular factory where modules are manufactured and the construction site, (b) a telescopic boom crane to load modules from laydown yard to truck for transport to project site, (c) a lattice boom crane to unload modules from truck and place them in their correct position according to design. Figure 6 shows the ConStrobe DES model for the process that details how these key resources along with the truck(s) come together to move the modules from the laydown yard to its final installation site.
Decision variables of interest relating to the process and product based on available resources (type and capacity of cranes) could include determining the correct sequence of installing modules, buffer size of laydown yard, number of trucks to be used etc. The framework was successfully applied to this project to determine the resulting schedule of installation based on given product design, process design, resource capacity and inventory, and variability in activity durations, as shown in Figure 7. Figure 7 further shows how decreasing the number of available laydown space did not have an impact on the total schedule, while increasing the number of cranes and trucks for module installation reduced the project schedule considerably. This shows that the critical bottleneck in the operation are the cranes and not the laydown yard, which illustrates the use of the methodology for operations analysis.
This work is just the first step in the analysis of the integrated framework to use information from the BIM model to inform DES model processing. Future work will involve further experimentation with resource allocation and different sequencing of installing modules to determine optimal operation performance. These efforts demonstrate how product-related information (from BIM) can enhance a process model (in DES) to provide a sum greater than the parts.
