1。4。

Object oriented approach to safety risk drivers

Quite apart from acknowledging the existence of the risk dri- vers, a project manager needs to determine which and how risk drivers are interfering with the progress, i。e。, the drivers have to be defined in such a way that they can be assessed using available tools。 A set of drivers expressed in a format non-quantifiable by available tools will not help the manager overcome their safety issues。 Checklists were probably the most usable tools to identify safety risk drivers when the clauses entailing visual inspections were being passed, but today, interactive smart software widely used to check criteria instead of filling a predefined static checklist can bring so much more to the table。

To set a criterion concerning the existence of a certain driver, one should note that most current building design technologies implement the concepts of ‘‘Object Oriented Programming” (OOP), that is, while the safety codes are composed of pieces of text, elements in available software are ‘‘objects” (Zhang et al。, 2013), each representing an instance of a ‘‘class”, which is a data structure comprised of attributes and procedures。 Classes are arranged in a hierarchy that allows the objects to inherit properties from their ‘‘superclasses” or ‘‘families”, and interact with other objects。

It may be cumbersome in some situations that an object can only be defined if sufficient information about the superclasses or families is obtained。 A famous critique on OOP, for instance, analogizes the calling of an ‘‘object” to asking for a banana and being presented with a gorilla, who is surrounded by the whole jungle and holds the banana (Seibel, 2009)。 However, in a risk iden- tification context it is good practice to know which other elements are surrounding or hosting a discussed element, since potential relations or dependencies may give valuable clues to unregarded risks。

Before BIM emerged, efforts to automate risk identification pro- cess could not concentrate sufficiently on the risk itself, instead, they spent a lot of effort on parsing the drawings, or trying to figure out what the overlapping multilayered 2D polylines and arcs actu- ally contain。 Ding et al。 (2012) proposed a risk identification sys- tem based on analyzing construction drawings, which would detect potential hazards with regard to some defined pattern of shapes and hatched areas。 Having put much effort on analyzing the drawings, the authors acknowledged  the  benefits  of  using BIM to extend their risk identification system (Ding and Zhou, 2013)。

As a matter of fact, rather than putting together lines and cir- cles, or even 3D boxes or cylinders, a BIM platform consists of 3D ‘‘objects” that are already aware of what they are, to which family they belong, of which material they are made, and when and where they will be installed。 This will make it possible to see if an object, or a set of objects with all possible relationships and dependencies, complies with or violates a specific safety requirement, provided that the drivers of the risk in question are to a greater extent known。

1。5。Paper layout

After introducing safety risk drivers as the missing link that would propel the concept of DfS, the rest of this paper is organized as follows。 Section 2 describes how accident cases are gathered and analyzed in a structured framework to decide whether they are related to design, and how the factors driving up these accidents are classified in this paper  in  accordance  with  object  oriented BIM capabilities。 Due to the limited literature on risk drivers, a the- oretical framework to define risk drivers, and a summary of the drivers found in the literature of  construction  risk management are provided in Section 3。 Section 4 presents five sets of drivers