Adapting LOD definition to meet BIM uses requirements and data modeling for linear infrastructures projects: using system and requirement engineering

In BIM community, Levels Of Detail (LOD) and Level Of Development (LODt) are now crucial concepts that have to be integrated globally way to standardize the description of information. In construction projects and more specifically in building projects, LOD or LODt have several definitions (Bolpagni and Ciribini 2016). LOD for infrastructure project do not seem to exist, except that of PAS1192 which remains partial (PAS 1192-2 2013).

The Level Of Development (BIMForum 2016; BIMProtocol 2013; Kreider and Messner 2013) or Level of Definition (composed of Level of model Information (LOI) and Level of model Detail (LOD) (PAS 1192-2 2013) transcribe the evolution of the design. They are based on model needs to meet at the project stages or data drops and enable consistency in communication and execution by facilitating the detailed definition of BIM milestones and deliverables (BIMForum 2016; BIMProtocol 2013). For instance, for BIMForum, LOD 350 would define model elements sufficiently developed to enable detailed coordination between disciplines – e.g. clash detection/avoidance, layout, etc. (BIMForum 2016). LOD of CityGML is also defined in a similar way: each LOD is dedicated to certain analyses (CityGML standard 2012). The LOD is sometimes defined as how much detail is included in the model element (as an input). But sometimes LODt is divided into the current LODt of the element and the LODt specified for that element as defined in the model element table. But in the design process, one stakeholder uses information from another stakeholder. The second stakeholder uses the LODt of the first as a LOD. How to transform LOD in LODt even though they are defined as different in BIMForum (2016)? Moreover, it is common to have a digital mockup composed of objects with various LODt. In these previous definitions, the concept of LODt seems to be applied to objects but in fact it is applied to a set of objects (Fig. 1). This indicates that the abstraction on the project is considered implicitly. Consequently, object modeling is more related to the working scale or to the stages and milestones than to a stakeholder point of view or design needs to reach product requirements. These definitions and uses of LOD and LODt are not compliant with the defined approach of information management and modeling based on requirement engineering for the definition of BIM uses (Tolmer 2016).

Next, in infrastructure projects, we have to model the existing environment such as buildings, networks or other infrastructures or civil works and consequently to consider the CityGML standard and its own definition of LOD, which have been defined for this purpose. Moreover, a working group in European standardization (CEN/TC 442/WG 2), called Task Group 1 (TG01), is in charge of proposing a new work item for the end of 2017. We therefore had to analyze the different dimensions contained in these different concepts of levels of detail of project information. To do this, we used the approach to decompose LOD (Biljecki et al. 2014). Six dimensions, called metrics in Biljecki et al. (2014), are identified to describe LOD (Table 2)

They reflect, according to the authors, the elements generally and implicitly included in the definitions of LOD or LODt mentioned above.

Finally, in the definitions of all these LOD, LOI or LODt, including CityGML’s LOD, the description of an object, through these dimensions, is sometimes explicit and sometimes implicit (Table 3). Moreover, neither of these concepts is yet standardized (Bolpagni and Ciribini 2016) and is therefore subject to interpretation.

The LOD is also the bases for information modeling: what quantity of information, what precision, accuracy or detail for each modeling object? But the first step in modeling is not included in the definition of LOD. Thus, we introduce the concept of Level Of Abstraction (LOA) to select the relevant information and objects that have to be used to meet each requirement. However, to select the relevant abstraction of the project (similar to a stakeholder point of view), requirements have to be identified (Tolmer 2016; Tolmer and Castaing 2017).

The main objective of a design project is to meet project needs. These needs are transformed in requirement during the design. Thus, requirements are more and more detailed and precise. They also have to be managed through all the infrastructure life cycle. However, requirement management cannot be viewed in isolation of system engineering (Badreau and Boulanger 2014; Fiorèse and Meinadier 2012). System engineering adduces the concept of System. As we will see bellow, this concept is fundamental to break down an infrastructure project. Our work presented here is to define processes to describe BIM uses and IDM, based on requirements. Consequently, we propose to use Requirement engineering, which is part of System engineering. Requirements engineering refers to the process of defining, documenting and maintaining requirements to the sub-fields of systems engineering (Kotonya and Sommerville 1998).

We propose a top – down approach based on system engineering and requirement engineering. This work allows defining the system we really study, its environment and interfaces. It also allows identifying the relevant information and objects considered by the treated requirements of a BIM use and also the processes to manage this information. Then, LOD concept will be needed to precise the detail on used information. For it, System engineering well separates the project-system that creates the product-system (Fig. 2). Needs are defined in the contract and in regulation. A system consists of a set of elements whose synergy is organized to meet a goal in a given environment (Fiorèse and Meinadier 2012). A project is a unique process, which consists of a set of coordinated and controlled activities with start and end dates in order to achieve an objective conforming to specific requirements such as the constraints of time, cost and resources (NF ISO 10006 1998).

Lastly, system engineering introduces different type of visions. They are defined in Table 4 through a series of questions. These three visions allow identifying clearly the external part of the designed system. This external part defines the first stage of “needs” (operational requirements). It is the problem domain (Badreau and Boulanger 2014): consequently the product-system has to meet these needs. Requirements are also structured following the three visions: they concern both project decomposition and project requirements. In theory, links have to be created between objects and requirements (Fig. 3). The object decomposition is guided by the vision and partly by the level of detail of the information. That is a reason why the concept of level of detail of the used information has to be compliant with the use of system and requirement engineering. Functional requirements address to the project systems and organic requirements address to the project components (performances for example). It is the solution domain (Badreau and Boulanger 2014). In addition, a distinction is made between process requirements and product requirements, based on (Badreau and Boulanger 2014) and (Tolmer 2016).

It is not possible to study all the product-system in one time. Therefore, some significant uses cases have been identified. They cover different domains and different working scales (especially with acoustic studies). In our work, a use case is a sum of activities in a domain that allows answering product requirements. A BIM use is the definition of processes and used information to use BIM in a specific use case. The three uses cases described below are part of the whole product-system of the design project. They allow to address different kind of systems and objects of the whole project. They represent domain use cases (acoustic and drainage) and coordination use case considering other requirements than the 3D coordination (safety audit).

These use cases are based on the urban highway project in Marseille, France, the L2 project (Fig. 4). It is a 10 km connection between two other highways inside the city. At present, this project is the most important infrastructure construction site in France. Registration of the project on the zoning map of Marseille was done in 1933. On October 7, 2013 a Public Private Partnership was signed with the company SRL2 for a total of 624 million euros. The part financed by the institution amounts to 150.6 million euros over 5 years. The part financed by the French State amounts to 150.6 million euros over 5 years. The L2 bypass should be delivered in 2017, and the East part has already been opened. For each use case based on this project we define elements that have to be considered (Table 5). The first two authors of the paper were involved in the project to define BIM processes. They participate in workshops defining BIM processes at the beginning of preliminary design until detailed design. These three use cases have been defined during the project in relation with the design team and also with the client (contractor here). The content of these use cases were improved after some uses during all the design. All needed data were available to the authors to make experiments because they participate to the project as part of the designer design teams for BIM implementation. The first author was a PhD student in Lab’Urba working on urban engineering researches. These experiments were followed by the two last authors, working for this public laboratory. The authors do not declare any conflict of interest since this work was intended to validate an approach within the framework of the national research project MINND, where the whole construction sector participates. The approach is accessible to the public and can therefore be verified easily without any compensation from the authors.

Some description elements are given bellow:

For these three use cases, we identify important elements of the product-system of the design project. It is about workflows, 3D objects, level of detail of used information, requirements identification and definition (defined by system and requirement engineering described above) and relations between systems and objects (Table 5). 3D objects and level of detail of used information are considered in the three use cases. They are fundamental parts of the definition of exchanged information in BIM. Furthermore, the relations between objects, systems and requirements are the base of the product-system. These three use cases are complementary and recurring on linear infrastructure project.

To maintain consistency between defined models in each use case, we selected proven and well known formalisms. The first one is UML: it is used modeling conceptual data models for instance. It allows to describe many aspects of models, keep consistency and facilitate interaction between collaborators defining the project conceptual data model (Nugroho and Chaudron 2009). The second formalism is also well known in the industry. It is called Structured Analysis and Design Technique (SADT). It allows giving a framework to define an activity: incoming, outgoing, all constraints and also supports of the activity. The last one called PERCEPTORY is used to describe spatio-temporal database. It is a UML profile (Bédard 1999) (Fig. 6, right hand side). We propose to use a combination of these three formalisms to clearly define 3D objects workflows and also geometric and semantic transformations they undergo during the entire process to meet requirements (Fig. 6 left hand side).

Existing LOD have been analyzed regarding six dimensions related to object modeling (Table 2). LOD implicitly include different dimensions. The Level Of Detail (LOD) defined in the CityGML standard (CityGML standard 2012) facilitates the visualization and the analysis of data. For instance, an object can have different representations for each LOD which enables analysis and visualization of the same object with several degrees of resolution (Groger and Plumer 2012). This approach considers the needs of stakeholder. However, the objects modeled for a LOD are defined in a generic way for the entire project: it is not the most relevant way to organize project objects modeling (Tolmer et al. 2015). Then, LOD of CityGML structure implicitly modeled objects in a single hierarchical tree: for a higher LOD, an object is split into multiple objects. However, this unique structuration approach is not sufficient as we will see in the example below. The object description and modeling depends on its context and the way it will be used and is not only related to the scale we observe it with, even though some scale depends on the analyses. In this way, this concept of LOD cannot be used alone in an infrastructure project as also stated in Borrmann et al. (2012). A concept of higher abstraction level must be introduced to integrate the context of use of the objects and the requirements it has to meet. In the modeling process, the first step is to select the simplification of the reality we have to consider. It is an abstraction of the reality as defined in different domains considering modeling (Bouzeghoub 2006; Hascoët and Beaudouin-Lafon 2001; Ruas 2004). Thus, we proposed to introduce the concept of Level Of Abstraction (LOA) to account for this need. It use is describe bellow in use cases results. The levels of detail described below do not explicitly consider this abstraction step in modeling.

From a certain point of view, all definitions of LOD (or LODt) are similar in the sense that they embed the same interdependent dimensions (geometric complexity, semantic, etc.,

Table 2) through a unique concept, called Levels Of Detail, Level Of Development or Level Of Definition, but with a different weighting of this dimensions. It has to be noted that certain definitions tend to separate information (which treat attribute and semantic part of an object) and detail (which deal exclusively with the geometry of the object) (PAS 1192-2 2013). It is also a proposal for the next CityGML standard version (Lowner et al. 2013). Again, these proposals are not yet standardized. It should be done to allow describing information exchanges requirements in a common way.

Table 3 summarizes the results of analyzing of different types of Levels Of Detail through six dimensions. It is important to note that almost all dimensions are considered but with around half in implicit way. In addition, all dimensions are not managed in a similar manner for each type of Levels Of Detail. Thus, it is not possible to use LODt for design and LOD from CityGML in infrastructure projects while it is necessary as explained in introduction.

The second stage of the bottom-up approach is to identify all the elements impacting the product-system. For a design project, we consider that the product-system, the design result, is composed of the conceptual data model of the infrastructure project and the data base of the project. That means object modeling with the relevant level of detail of the information, according to the design phase (or phases). It is a part of the whole product-system (Fig. 7). In the design project, the deliverable is only the modeling of the project and not the constructed project with its digital mockup and database. The product-system of the construction phase has to be, considering BIM processes, the constructed project with operating system and its digital mockup, modeling the project as-realized.

Applying system engineering and requirement engineering on infrastructure design project demands adaptations for the construction domain. It is not a classical way to see a design project. Requirements are not easily identifiable and are derived from different documents, such as regulation, client documents but also internal processes. The main difficulty stems that today BIM processes and current processes are differentiated in contract (Fig. 8). Consequently, processes requirements are divided in two parts, BIM and currents processes requirements. It is complicated to consider in the same BIM use this separation, operating on a common process. Considering product requirements and their objects is, according to us, a solution to then define processes requirements without the consideration of BIM processes and current processes. It doesn’t make sense when project data model is based on requirement engineering.

Figure 8 retains classical terms of system engineering and requirement engineering, direct environment and indirect environment in our case. It makes the distinction with elements that directly influence the product system and the others elements. We also identify which elements are considered to define BIM uses and consequently have to be coherent together, especially in 3D object consideration and formalisms utilization.

As demonstrated in Tolmer 2016, applying system engineering on infrastructure projects allows the identification of the real scope of BIM uses. To define the BIM uses content, the product-system, the project-system and their relating requirements have to be considered. Lastly, Fig. 8 shows that BIM uses are directly in interaction with the BIM Execution Plan, the Project Management Plan, the contract and the Regulation. All these elements contain the project requirements, for product-system and project-system. The project-system is composed of two elements. The data model (the conceptual way to organize information) that can be composed of several conceptual data models or standards, and the data base of the project that include all the information used and produced. Although the levels of detail of the information are defined in the BEP, they are included in the Fig. 8 in the BIM use domain, because this is where they are applied. The BEP include other elements as computer architecture, nomenclatures, stakeholders, all validation workflows, etc. Finally, Project management guide and BIM guide are placed in the internal framework of the design company as it is in Egis (Egis is involved in designing and operating several types of building and infrastructures projects: road, rail, airport, dam, networks,…). They are both guides. However, depending on the content of this BIM guide, it can also be a contractual document.

This use case has been made during the national French research project MINnD. As explained above, the first stage is to apply system engineering. The use case Sizing acoustic protection is a part of the whole design project (project system defined by system engineering). The acoustic protections defined in this design activity are part of the whole product system of the design project of Figs. 7 and 9). Secondly, the workflows and exchanges between stakeholders of the project, concerned by the acoustic studies, are described. The main purpose of the acoustic studies is to define recommendations about noise barrier and other acoustic protections (Fig. 10). Each step of this design process according to the formalism proposed above in section 2.4 are described (Fig. 11 as an example). This Figure concerns the noise barrier which is the most classical 3D object of acoustic protection. It shows the loss of information at each step. For example, the object at the beginning and at the end of stage 2 is clearly different: the object properties are separated from the object. The link between attributes and object is lost because of interoperability problems. Other objects such as digital elevation model, roads (existing and design), buildings, tunnels, existing walls, isophones and local weather conditions have been studied. This description allows to see the differences between expected level of detail of the information and the real one permitted by tools and design processes.

These elements, describing objects, attributes, workflows and stakeholders, are sufficient to describe certain IDM in accordance with ISO 29481-1 (2016). UML use case diagrams describe the stakeholders. Processes (Fig. 11) can be uses to describe the exchange requirements and process map.

This use case gather numerous requirements concerning security, traffic regulation and monitoring, safety equipment, visibility, directional signs, etc. (Fig. 12). It also have a lot of interfaces with others domains. For example, the concrete barrier can participate to the drainage system and consequently to the response to the water regulation. Quite a few objects of the safety audit belong to plenty of systems. Moreover, requirements are usually related to several different types of objects (objects classes) and different systems (Fig. 13).

First, a significant number of requirements, regarding to the safety audit are identified (in compliance with requirement engineering: operational, functional and organic requirements). To allow the structuration of these results, a new definition of LOD has been proposed. LOD (Level Of Detail, means geometrical information) and LOI (Level Of Information, means non-geometrical information) are similar to the definitions in PAS 1192-2 (2013). However, we propose a new level that takes into account the stakeholder point of view, changing for each BIM use (and use case of course). Each requirements considered in BIM uses require a specific modeling. The Level Of Abstraction (LOA) we propose here should help to identify the relevant objects that have to be considered for each BIM use. It takes into account the modeling methodology in three stages adapted of Bouzeghoub (2006):

We propose here to write LOX to consider LOD, LOI and LOA. This is just a naming convention to facilitate the paper comprehension. These levels are analyzed with the same dimensions proposed by Biljecki et al. (2014). They all are managed in an explicit manner by LOX. Moreover, they are decorrelated. This way, they can easily be defined for each object, according to all requirements considered in each BIM use (Table 6). The Fig. 13 and Table 7 show two different ways to present results. Conceptual data models are defined for objects considered in safety audit use case. It includes the 3D object with its LOD and LOI, the systems (or functional structure) in which it is included, and requirements (Fig. 13).

The Fig. 13 presents only one 3D object and all his relations with requirements, systems and functional structures. This decomposition is not detailed here but it is a current way to divide space and to identify in the same time important constructed works. It has been shown in a precedent research project that it is a key concept to describe a linear infrastructure project Communic (Communic Deliverables 2010). Thus, in Table 7 we present some of the 3D objects and related information (LOD and LOI) to answer to only one requirement (called here SC – 9). Defining which object is relevant to meet a requirement is the way to define what is called LOA (Table 7). It is also a part of BIM use and IDM definition.

First, the environment of longitudinal drainage system is defined (similar approach than Fig. 9). It allows to identifying and describing product requirements (Table 8). Then, all needed objects to fully describe the drainage system are identified (abstraction phase, LOA). This description includes object attributes and representation (LOD and LOI). This information is only changing with the phases. This use case seems to be a simple one. Indeed, requirements are almost the same for each objects of drainage system (operational and functional requirements only). Three different systems are distinguished: longitudinal drainage, transverse drainage and impluvium (set of surfaces collecting run-off water for sizing the hydraulic structures). However, we noticed some important elements. For example, constructability is usually verified in the design phase. But, if the objects belong to a critical or complex functional structure, it has to be verified in preliminary design. We find here an interest to start defining a BIM use with requirements definition. Likewise, there is an interest in organizing objects structuration connected to systems, functional structures and spaces like environmental sensitive zone.

The aim of this use case was to identify all needed information to propose a real conceptual data model to implement in actual tools. Geometric complexity and semantic are not considered here. Depending on the considered requirement, the objects modeling are different (Table 9). The presence of objects in the model is not present in this table: the selection is made in the previous stage which is abstraction.

The difficulty of this use case does not spring of the definition of objects and related information. We identify complexity with the treatment of interfaces with other domains (geotechnical study, earthworks drainage, environmental studies), the transversely of the drainage system with other systems and functional structures and the connection with existing networks. Consequently, the BIM uses for designing drainage system can’t be entirely defined. A work about interfaces between longitudinal drainage and the rest of the project is now in progress. It should be generalized to all longitudinal systems as safety barriers for instance.