To guarantee the success of a construction project, a detailed process model speci cation is essential. The peculiarities of the domain, like the high number of details, the participation of multiple parties with di erent strategic goals, and the need of exibility, make generic process modelling languages unsuitable. For this reason, the PRECISE methodology has been recently introduced by a group of civil engineers. PRECISE introduces a domain-speci c graphical language, successfully employed in real construction projects. However, currently the language su ers of some limitations and ambiguities that prevents the development of tools for supporting the project management and possibly implementing automatic functionalities. In this paper, we highlight the problems related to the language and propose an extension to overcome them. The resulting language can then be formalized in Linear Temporal Logic formula over nite traces, paving the way for the development of (automatic) supporting tools.
Process management in construction aims at de ning and executing a construction process, guaranteeing a high quality of the nal product and limiting time and cost overruns. Some peculiarities of the domain make this task challenging in reality. One aspect concerns the high number of details to be considered: besides de ning the tasks to be performed, it is also necessary to specify the di erent locations where each of them is foreseen and the resources needed, potentially shared among di erent tasks. An e cient management of resources is important and aims at maximizing their usage while ensuring their availability when needed. These aspects require coordination among the di erent crafts that participate in the construction process. In fact, companies prefer to coordinate among themselves rather than working for general contractors, because the pro t margins are lower in this case. As a consequence, before the process can start, the companies need to agree on the way the activities will be carried out. Accordingly, modelling the process is important for an e cient management of the resources and to ensure good quality of the nal result. The process model needs to be exible so that it can be quickly adapted to face unpredictable events (e.g. bad weather conditions) or changes of the requirements (which often occur in construction projects).
In the literature, two main approaches for process modelling exist: i) the
data-centric one, which identi es a number of relevant entities and describes the
process in terms of their possible evolution; and ii) the activity-centric one, which
focuses on the activity control ow, representing the data in a very limited way
(e.g., BPMN [
To meet the peculiarities of the constriction domain, a group of civil engineers
introduced a new domain-speci c methodology, named PRECISE (Process
REliability in ConstructIon for SmEs) [
In this paper we focus on the process modelling phase of the PRECISE methodology for which a domain-speci c graphical language has been introduced. The modelling is conceived as a collaborative activity to be performed by all the key actors taking part in the construction project. The resulting process model encompasses all the details that are needed for the di erent companies to synchronize and coordinate their activities on-site. A model constitutes the basis for the subsequent phase of the methodology, which is the scheduling of the activities to be performed on-site. According to PRECISE, during the modelling the following elements are de ned: i) a representation of the building in terms of locations, suitable to locate the tasks to be executed; ii) the resources that are needed; iii) the tasks to be executed and on which the di erent crafts have to synchronize; and iv) the dependencies on the execution of the tasks.
In this setting, two main modelling requirements emerge: the modelling language should be easy to use and understand, and a model must be non-ambiguous in de ning the activities of the di erent companies and the dependencies among them. This is important both to achieve the desired coordination among the companies and for the implementation of (automatic) supporting tools. Currently, the language is used with limited support of IT and automatic tools (e.g., process models are de ned on magnetic whiteboards) and it presents some ambiguities that are usually solved by annotating a model with additional information (e.g., with notes and comments) that is not part of the language. In this paper, after presenting the limitations of the PRECISE modelling language (Section 2), we propose an extension which allows one to overcome the described limitations (Section 3). We conclude by describing the future work of formalizing the language in terms of Linear Temporal Logic (LTL) (Section 4). 2
According to the PRECISE methodology a process model is graphically represented as a graph where nodes are tasks and edges are dependencies among them. A task is represented as in Fig. 1 and contains the following information: ¬ a unique task id ; the number of workers and ® the number of days needed to complete the task; ¯ the responsible craft ; ° the activity to be executed; ± a space for annotations; and the information on the locations where the task is foreseen. The PRECISE language does not de ne a standard for the representation of the location. The gure refers to an example were locations were identi ed as pairs of ² section, which de nes the technological content of an area (e.g. room, swimming pool) and ³ level, i.e. a oor of the building. Tasks are connected one with another by means of precedence dependencies, represented as arrows. These declaratively specify the set of constraints that a schedule needs to satisfy. Accordingly, several schedules may satisfy a process model.
Fig. 1 reports an excerpt of the process model of a real construction project
for the construction of a hotel [
Preparation 2 6 10 Di
Excavation **
** Task Representation
Æ#days ØCraft ≠ #workers ¨id 8 2 20 Pl
Pipes Installation ∞Activity ± Description ≤Section ≥Level
Floor heating, radiator uR1 uC1 fR0 3 3 40 Br Concrete Pouring this point, the Pipes Installation can start in the room (R) and in the corridor (C) of the underground oor (u1), and in the room (R) of the ground oor (f0). Note that these ambiguities are solved by expressing further requirements in the description eld of the tasks (e.g. as in Scaffolding Installation description). However, a model should be a non-ambiguous agreement among the parties, so as to allow one to determine, for instance, whether it is satis able or whether a schedule is compliant with a model.
As highlighted by this example, some limitations of the language emerge. We describe them in the following. (a) Representation of locations. The PRECISE modelling language does not foresee a unique representation of locations, which can be speci ed in di erent ways depending on the project. A standard way for representing them would allow for the implementation of tools for supporting the process modelling, and for the de nition and reuse of common modelling patterns in di erent projects. (b) Ordering on the execution of a task in di erent locations. A task is represented together with a set of locations where it is foreseen. In some cases, the order in which the task is executed in these locations matter. For instance, considering the task Concrete Pouring: its execution has to be performed from the lowest level to the highest, but this is not captured in the model. (c) Scope of a dependency. Currently, when two tasks are connected by a dependency, it is not clear whether the precedence constraint applies at the level of task or of location. For instance, the meaning of the dependency between the tasks construction site preparation and Excavation is that the rst task needs to be nished in all locations before the second one can start. The dependency between tasks Scaffolding Installation and Concrete Pouring, instead, applies at the level of oor. (d) Di erent kinds of precedence constraints. When the scope of a dependency is at the level of location, it is not clear whether the rst task has to wait for the second one to be completed in the same location before it can progress somewhere else (like a chain execution), or this is not required. In the example, for instance, not only Scaffolding Installation has to be performed before Concrete Pouring, but the installation of the sca olding cannot progress to a subsequent oor until the pouring of the concrete is nished in the previous one. Thus the two tasks have to be executed in chain. This is not always the case. If we consider tasks Painting and Cleaning, then the former task can start in every location without waiting for the second one to be nished. 3
In this section we propose an extension of the PRECISE modelling language,
making it able to address all critical aspects discussed in Section 2.
(a) Representation of locations. From the real projects where the methodology
has been applied we identi ed the following elements as suitable to represent a
building in an abstract way [
Sections: identify the technological content of certain areas (e.g., swimming pool, corridor, room and such like).
Units: a unit is a number used to enumerate locations of the same kind. For
instance, di erent rooms at the same oor have di erent unit numbers.
We will refer to this representation as the construction area hierarchy. With
slight abuse of terminology, we will refer to a construction area (CA) as a location
speci ed at di erent levels of the hierarchy, that is a sector, a pair sector-level, a
triple sector-level-section or a tuple sector-level-section-unit are all construction
areas. The latter, in particular, provides the highest level of detail in
representing a location. We refer to it as construction unit. For instance, the tuple
hA; f 1; room; 2i represents the construction unit at sector A, oor 1, room 2.
µintra-task precedence constraint A task is then foreseen to be
perÆ#days formed in a number of construction
≠ #workers ØCraft units. To represent this information
∞Act¨iviItdy 7 SIncs4atf<aflolalldt3iionng Sc twaeskA,esxatssehnreodpwontrh,teead rcienopnFrsetisgreu.nc2tt.aiotinonunoitf ias
±≤SLeecvtoerl fA0 fA1 fA2 represented in terms of ± sector,
≥ Section * * * ² level, ³ section and ´ unit. The
¥ Unit * * * wild-card can be used instead of the
Fig. 2. Representation of a task. unit number (e.g., hA; 1; room; i) to
identify all units of a section at a
particular level of a sector. The wild-card can also be used for the other elements
of a construction unit, if all elements below in the CA hierarchy are also .
(b) Ordering on the execution of a task in di erent locations. In some cases
it is necessary to specify intra-task precedence constraints, expressing that the
execution of a task in di erent construction areas must be performed following
a given order (as for the task Scaffolding Installation in Fig. 1, which has to
be performed from the lower level up to the top one). An intra-task precedence
constraint can be speci ed at di erent levels of the CA hierarchy to capture, for
instance, that a task needs to be performed following an order on the construction
units, on the oors (e.g., from the rst to the last oor, regardless of the execution
in the units within a oor) on the sections or on the sectors. To express this kind
of requirements we introduce the notion of scope which identi es at which level of
the CA hierarchy the constraint applies. Possible scopes are sector, level, section
or unit and are graphically represented with the symbols <sr, <l, <sn and <u
resp., as depicted in µ in Fig. 2.
(c) Scope of a dependency. To specify at which level a dependency applies we
introduce a notion of scope which is similar to the one introduced for the
intratask precedence constraints. The scope allows one to specify that, for instance,
a dependency between two tasks applies at scope level, i.e. in every oor where
the two tasks are foreseen, the rst task must be performed before the second.
Additionally, we consider task to be a possible scope for the dependencies. This
is used to express that a certain task must be completed (everywhere) before
another task can start. Graphically, the scope of a dependency is speci ed by
annotating an arrow with the symbols t, sr, l, sn and u to represent task, sector,
level, section and unit scopes resp. (see Table 1).
(d) Di erent kinds of precedence constraints. By taking inspiration from
Declare [
Chain Precedence. This dependency between two tasks A and B, is used to specify that in each construction area (at the speci ed scope) shared between A
Ordered Existence: ordered existence(A:task, Lo:fCAg, <s:order) id # # C
A id #<s# C
A
Task Precedence: task precedence(A:task, LoA:fCAg, B:task, LoB:fCAg) id # # C t id # # C
A B
CA Precedence: CA precedence(A:task, LoA:fCAg, B:task, LoB:fCAg, s:scope) id # # C s id # # C
A B and B i) A must be executed before B, and ii) once A is started in a CA c1 it cannot progress in another CA c2 until B is nished in c1. Graphically, this is captured with an arrow with an X symbol closed to A, to capture that, in order to progress, A has to wait for B.
Strict Sequence. In some cases it is necessary to specify that a certain task must be started immediately after another one is nished. A strict sequence dependency allows to express this requirement and is represented with a double arrow. Similarly as before, it is applied only to construction areas shared among the two tasks and it is speci ed at a certain scope. 4
In this paper we presented the PRECISE methodology for construction project
management. In particular, we focused on the process modelling phase and
highlighted some limitations of the original language, on the one hand related to the
lack of abstractions needed for capturing relevant constratins, and on the other
hand connected to the ambiguity of the language, which prevents the
implementation of automatic supporting tools. To overcome these issues we proposed
an extension of the language, which also paves the way towards the de nition
of its formal semantics. In particular, we are now formalizing the di erent
dependencies in terms of Linear Temporal Logic [
Acknowledgements. This work was done within the research projects MAGIC, nanced by the Province of Bolzano, and MoMaPC nanced by the Free University of Bozen-Bolzano. The authors thank Ognjen Savkovic for the discussions.