CoPMod is a proof-of-concept tool for supporting a collaborative construction process modeling approach that has been developed in a research project and tested in real construction projects. In the tests, the approach was applied using a semi-formal graphical modeling language and drawing models on whiteboards. CoPMod is the rst IT solution to support this approach, for which a formal de nition is provided in [4]. CoPMod represents the rst step in the context of the research project COCkPiT, which aims to develop IT-tools for construction process modeling and automatic scheduling and analysis.
Construction process models are meant to de ne the coordination among several construction companies simultaneously present on site, which have to perform di erent tasks in shared locations. The coordination should specify an agreement on the task execution such that workers do not obstruct each other and the prerequisites to perform a work are all satis ed when it has to start. For instance, the window installer and the oor layer should agree whether windows must be installed before laying the oor or the other way around.
The speci cation of temporal requirements is at the basis of most of the
existing process modeling languages (such as BPMN, Petri Nets, Declare [
Traditional approaches in construction are the Critical Path Method (CPM),
the Program Evaluation and Review Technique (PERT) and Gantt charts. All of
them abstract from some crucial details that make them di cult to be used for
? This work was supported by the project COCkPiT nanced by the European
Regional Development Fund Investment for Growth and Jobs Programme 2014-2020.
execution and process control. In particular, they abstract from locations and
from location-based relationships [
We de ned CoPMod, a proof-of-concept tool aiming at supporting the
collaborative de nition of a construction process model. Collaborative means that
project managers and foremen from the di erent companies meet and actively
take part in the modeling. The foundational aspects of the approach are
described in [
We describe CoPMod by means of a simpli ed example for the construction of a hotel. We consider two phases of a construction process execution, the skeleton and the interior construction, and we consider three companies: Sk responsible for the skeleton, WI for the window installation and FL for laying the oor.
To maximize their productivity and reduce waste, the three companies have to de ne a coordination plan in executing their activities, which we call process model. The Sk company comes rst and has to make the excavations, secure the area and build the foundations. The hotel consists of two separate buildings: the main building (B1) and a complex of luxury rooms and wellness center (B2). It must be clear where the work needs to be nished before the other companies can start. Excavation and Secure Area must be performed everywhere before any other work can start. However, the construction of the foundations can be performed independently in the two buildings, and once it is nished in one building the other companies can start working there.
The WI and FL companies have to agree on how they want to proceed in putting the windows. The FL company would like them to be installed rst so that wooden oors are not damaged by putting the windows. At the same time, the WI company would like the wooden windows to be installed later, in order not to damage them when putting the oor.
The tool1 consists of a con guration and a ow part.
Con guration Part. CoPMod con guration part de nes: i) the structure of the building, ii) the crafts involved, and iii) the activities to be performed. 1 https://www.inf.unibz.it/~emarengo/copmod-tool.html
The representation of the building structure can be uploaded as a JSON le. It consists of a hierarchy of attributes (e.g. sector, level), which de ne the locations (e.g., one can say that sectors are B1 and B2 and that B1 is composed of three oors, while B2 of two oors). The tool supports the de nition of di erent construction phases (e.g., skeleton and interior) and a di erent representation of the building can be speci ed for each of them. It is indeed the case that skeleton uses a coarser representation for the locations than interior: skeleton identi es locations by sector and level, while interior also uses the section to identify the technological content of an area (e.g. room, bathroom) and the unit number. The companies can insert the activities they are responsible for and associate to them a responsible craft by means of a graphical interface.
Flow Part. The ow part supports the companies in drawing a coordination
diagram consisting of tasks, locations, and location-based dependencies among
them. The de nition is expected to be orchestrated by a moderator (e.g., the
project manager responsible for the project) who is expected to be familiar with
the modeling language supported in CoPMod [
Figure 1 reports the coordination for the hotel construction. First the moderator inserts the Excavation activity which belongs to the skeleton phase (represented with the blue color). The activity is represented as a box, where in the bottom part the locations where to execute it can be inserted. Locations are speci ed according to the representation de ned for the construction phase in the con guration part. In this way, the Sk company can specify that Excavation is performed in both buildings at the underground level (u1). The top of a task box shows: i) a task id (automatically assigned); ii) the number of crews currently assigned by the company to the task and the number of workers needed to form a crew (e.g., 1 6); iii) the expected duration to execute the task (e.g., 10 days); and iv) the acronym of the assigned craft (e.g., Di for digger). The expected duration can also be automatically computed by the system if the crew productivity (e.g., pieces per day) and the total quantity are provided.
In order to specify that the excavation cannot be interrupted by other tasks, the moderator has to insert an exclusivity constraint. This type of constraint can be speci ed by means of the exclusiveness menu (see Fig. 1). The moderator can also specify that exclusivity applies at the level of sector (i.e., for each building separately). This constraint is graphically visualized with a double border for the task box with the label `ex: sr' for the scope of the exclusivity constraint. When the excavation is nished in one sector, the next task to be performed is Secure Area. No other tasks can be performed in between the two. This is expressed by inserting a dependency between the two tasks and selecting as a dependency type the \chain" constraint (double arrow) and sector as scope.
In the diagram, green colored tasks belong to the interior phase. Arrows represent precedences between tasks and can be labeled with the scope (no label indicates that all of the rst task must be nished before the following one can start). The dependency between Scaffolding Installation and Concrete Pouring is an alternate precedence, meaning that the sca olding must be installed in one level before the concrete is poured, and in order to proceed to the next level, the concrete must have been poured in the previous one. Checking Functionality. By relying on a con guration part de ning the building, the set of crafts and of activities, it is possible to reduce insertion errors (such as typos). Additionally, CoPMod checks for structure warnings and errors and consistency errors. Structure warnings show parts of the diagram that potentially can be rewritten in a better way, such as a location repeated in a task box, or cycles that do not create inconsistencies but that may mean that some constraint is redundant. Structure errors indicate that something is missing in the diagram (e.g., an activity is not associated to a construction phase). Consistency errors mean that the model cannot be satis ed by any execution. In Figure 2 several warnings and errors are signaled. For instance, the loop between Aluminum Window Installation, Lay Floor and Wooden Window Installation cannot be satis ed by any execution. The loop between Concrete Pouring, Fill Excavation and Scaffolding Installation, instead, is satis able and thus is not highlighted as a consistency error but as a structure warning. 3
CoPMod has been developed starting from a collaborative process modeling
approach. The approach was tested in real construction projects without the
support of IT-tools (using a whiteboard). CoPMod's current version is a
proofof-concept to show to construction companies the bene t of graphical IT-based
tools for construction process modeling. It has been presented to one
construction company during the process modeling of a real construction project. A
moderator was replicating the modeling steps that were carried out by the
project managers and foremen of the involved construction companies. For the
automatic checks that it supports, we developed an e ective ad-hoc checking
algorithm, which outperforms o -the-shelf model checkers. The algorithm
translates a diagram into a graph where nodes are activities to be performed in
one location and checks the existence of a cycle-free path in the graph
(resolving some non-determinism) [