Open Access

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

Visualization in Engineering20175:21

Received: 7 January 2017

Accepted: 21 September 2017

Published: 6 November 2017



Within the current organization of design activities it is difficult to fully realize the potential of BIM (Building Information Modelling). In BIM processes, it is necessary to identify and exchange the specific information that is relevant in the exchange information requirements of each project. The concept of level of detail of the information is a tool for describing and quantifying the information that should be exchanged. But the existing definitions of level of detail of information are not easily usable. Precise definitions of methodology, tools and principles are needed to redefine this concept and to use it in order to define the elements of information that are relevant to be exchanged.


The authors propose the use of System Engineering and Requirements Engineering to define BIM uses and the relevant level of detail of information and its modelling concerned by each BIM use. The authors first explain why, in this context, the existing definitions of LOD, which can mean level of detail, level of development, level of definition, etc., are not sufficient and not always coherent. They demonstrate through real use cases that System Engineering and Requirement Engineering are a part of this methodology and propose, using formalisms, to describe each BIM use in detail.


The authors apply two different approaches to defining the relevant information to each BIM use. Using a top-down conceptual approach they show that Level Of Detail (LOD) is a crucial element in defining the content of a BIM use. They then verify the practicality of their proposal using a bottom-up approach based on three use cases (acoustic studies, safety audit, sizing drainage system). These cases studies allow the authors to address different kinds of systems and objects within a whole infrastructure project. They represent domain use cases (acoustic and drainage) and coordination use cases (safety audit). This part of the work is based on the L2 project in Marseille, which is a Public Private Partnership for expressways.

As a result, a methodology is proposed both to redefine the level of detail of information concept and to describe how this concept is used to complete the BIM uses definition. The system engineering and requirement engineering methods are partially adapted to infrastructure projects. These elements facilitate the description of BIM uses expected in BIM Execution Plans. It was necessary to change the definitions of LOD in order to make them compatible with the methods of requirement management.


Design activities should be reorganized toward the common goal of meeting project needs and requirements. The authors demonstrate that the best way to meet requirements is to define BIM uses using a new definition of the level of detail of information. It has first to consider requirements that have to be reached through BIM and then define the relevant level of detail of information, using the concept of abstraction of reality. To do it well, applying system engineering and requirement engineering, adapted to infrastructure project, is required. To validate this proposal on an entire project, more use cases will be tested in further work.


Infrastructure modelingData modelingData managementSystem engineeringRequirementLODBIM useIDM


The linear infrastructure projects include a significant number of complex structures such as roads, tunnels, channels, networks, bridges or earthworks for example. They also have to take into account multiple stakeholders (engineering firms, manufacturers, builders, public administration). In addition, infrastructure projects are at the convergence of several scales of representation (territory to local scale) and degrees of accuracy as stated in Borrmann et al. (2012). In BIM (Building Information Modeling) processes, we have to share information. These exchanges need conceptual data models to structure information and tools in order to identify and select the relevant information in these data models. In the French research project called MINnD (INteroperable INformation Modeling for sustainable INfrastructures) (MINnD 2017), many experiments have shown that data modeling of infrastructures is not only 3D representation. In addition, data modeling is usually proprietary (technical specifications belong to the editor and are not available for users), barely collaborative and incapable to this date of handling the complexity of these infrastructure projects (MINnD UC 6-1 2016; MINnD UC-3 2016; MINnD 2014). Quite a few open data models exist for infrastructure. They are now in definition based on older works (Lee and Kim 2011; Obergriesser and Borrmann 2012; Yabuki and Li 2006). But these standards define all project objects and do not give tools to select relevant information. For example, buildingSMART propose to complete data models standards with Information Delivery Manual (IDM) and data dictionaries (buildingSMART 2014, 2017; ISO 29481-1:2016 2016; ISO 29481-2 2012).

An infrastructure project exists because of a client’s needs. Data consistency has first to be based to fit the client’s needs, the subsequent products requirements (describing object and systems performances) and not only on interoperability considerations. Using BIM and defining IDM could be the first step in considering products requirements to define information exchange requirements, workflows and data modeling. A BIM use is defined as a method of applying BIM during a facility’s lifecycle to achieve one or more specific objectives (Kreider and Messner 2013). Indeed, a BIM use is typically defined to meet product requirements (Kreider and Messner 2013) through information exchange requirements. Project BIM uses have to be defined not to change the project but only the way the project processes are run and the way to use BIM efficiently (Kreider and Messner 2015).

The concept of BIM use is closely linked to the level of detail of information concept to describe which project information has to be exchanged (Kreider and Messner 2013; Penn State 2011). In linear infrastructure project, we have to integrate geospatial information. In geospatial information modeling and in Geospatial Information System (GIS), the level of detail concept is generally dedicated to model objects with the most relevant geometry and representation according to a specific objective of analysis and working scale (Ruas 2004). A Level Of Detail (LOD) defined in the CityGML standard facilitates the visualization and the analysis of data for 3D city models. 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). The Level Of Detail (LOD) or Level of Development (we propose to note LODt to reduce confusion with different concepts called LOD) for design is to transcribe the design evolution. These different levels are not always compliant, they are not yet standardized, and they are subject to interpretation (Boton et al. 2015; Tolmer 2016). As explained in (Plume and Mitchell 2011), BIM and GIS has more than two standards to share and deal with. In fact, we orient our work to include GIS data in BIM processes. Furthermore, these comparisons do not allow us to resolve the problem of modeling information, based on the needs identified in the response to product requirements and information exchange requirements (first application on previous use cases).

For several years, as explained in (Bot and Vitali 2011) about modeling in engineering, industrial activities are more and more considering everything as models (Table 1). It is a new step after considering everything as objects (Bot and Vitali 2011). This paradigm is related to designed objects but also to the way of organizing the project stakeholders (INCOSE 2015). As mentioned in this Table, we need to consider “Multidisciplinary teams of designers involved in a common project”. This Table also details the need for defining codified processes and common data models for sharing models between teams. This paradigm is what we need to implement for building industry to concurrent engineering.
Table 1

Comparative table of the three design paradigms (Bot and Vitali 2011)


Design paradigm


Experimental design

Abstracted conception






Develop an adjusted artefact. Designing is creating on site.

Develop an industrial artefact. Designing is experimenting off-site.

Develop a generic artefact. Designing is modeling.


Mnemonic means (archetype), possible drawings exposing the solution in principle to the sponsor.

Means of physical tests, realistic models, possibly technical schema relating to a single domain (kinematics, hydraulics, electricity, etc.).

Abstract models that can be used by several trades and in different fields, possibly encoded in software.


The Master, his team of assistants or apprentices, the sponsor.

Experimental designers.

Multidisciplinary teams of designers involved in a common project.

Rules for community coherence

Sharing of the same archetype and verbal interactions, on site, between actors involved.

Sharing of the same design site: the design office, the service of the methods. Transactions with a distant manufacturer, going through detailed plans (counter logic).

Coproduction, sharing and circulation of abstract models between teams in the presence or at a distance.

Work division

The Master directs the activity of the team, ensures the finishing of the final artefact. His assistants or apprentices realize the details.

Taylor’s Division of Labor on the basis of disciplines (mechanical engineering, electrical engineering, etc.) or trades (product designer, Methodist, test manager, etc.).

Work divided from codified processes.


Design by producing the final artefact as soon as possible. This artefact consists of a variation of an archetype.

Design by producing as soon as possible a realistic model of the final artefact. The process is exploratory and empirical.

Designing by developing as soon as possible the models of the abstract artefact from which the concrete artefacts (the solutions) will be generated. The process is supported by prescriptive models that are also generic.


A final adjusted artefact.

Useful plans for mass production of the final artifact.

Generic models from which to initiate the design of many concrete solutions or processes.

In that sense, we have to consider objects modeling, which is the base of BIM. But project modeling and requirements modeling (product and process requirements about information exchanges) have also to be considered in all type of projects (INCOSE 2015) and through IDM and BIM uses for infrastructure projects (buildingSMART 2017; Kreider and Messner 2013). As we will see later, these three modeling objectives have to be connected and consistent with one another. To keep these three modeling objectives consistent, we should identify a methodological approach.


The advantages of BIM, especially on building project, are no longer necessary to demonstrate: many works have demonstrated, for example in (Burcin and Rice 2010; Fox et al. 2013; Tolmer and Ribeiro 2017). Contributing to using BIM in a more efficient way is the goal of our work. The BIM Execution Plan (BEP) should define the appropriate Uses for BIM on a project along with a detailed design and documentation of the process for executing BIM (Penn State 2011). The BEP has to be consistent with the Project Management Plan. Some elements such as stakeholders or information control processes are considered by these two production management documents. Through BIM uses, the BIM Execution plan describes: (the text in parentheses bellow describes what we propose to implement in our work to describe these constituents of BIM uses)
  • The considered product requirements (proposition of using system and requirement engineering),

  • The level of detail of the used information (proposition to verify if actual LOD definitions are sufficient and usable in this context),

  • The exchange information requirements between stakeholders (experiments based on use cases),

  • The processes requirements through the definition of workflows (experiments based on use cases).

Beyond the mere digital mock-up, exchanged information has to be defined. To specify these exchanges, we identify two important elements to use project data: the concept to describe the level of detail of information in BIM processes and the definition of product requirements by requirement engineering. They are the elements of our top-down approach: starting from concepts to experiments. We suppose that the concept of level of detail of the used information has to help to define the relevant information modeling to meet requirements. Thereby, system and requirement engineering are applied to the whole project to identify needs about information modeling. We then describe our bottom-up approach, based on domains uses cases to verify our proposal of applying system and requirement engineering to infrastructure project.

Several approaches and dimensions to levels of detail definitions

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).
Fig. 1

information specification for Floor Structural Frame (Steel Framing Bracing Rods) (BIMForum 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)
  1. 1.

    Geometric complexity: describe how high is the complexity in the object geometry,

  2. 2.

    Dimensionality: is about the object dimensionality: it is not relevant to model all objects in 3D, 2D or 1D object could be enough, even in a 3D spatial environment,

  3. 3.

    Appearance: is about the colors or textures of modeled objects,

  4. 4.

    Semantic: is about the objects semantics,

  5. 5.

    Presence: is to precise if an object is modeled or not for each consideration or BIM use for instance,

  6. 6.

    Attributes: is about attributes that have to be defined for each object.

Table 2

Dimensions to decompose and analyze the different concepts of LOD, based on Biljecki et al. (2014)

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.
Table 3

Decomposition of different existing Levels Of Detail regarding the six dimensions proposed by Biljecki et al. (2014)

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).

Adaptation and use of systems engineering and requirements engineering

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).
Fig. 2

Application of system engineering by (Fiorèse and Meinadier 2012)

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).
Table 4

Adapted of Krob (2009) for infrastructure project






Traffic speed, Achieve environmental constraints


What to do?

Inform users in real-time about traffic status


How to do?

Class of resistance of safety barrier

Fig. 3

Links between requirements and objects using decompositions according to the considered vision

The proposal tested on three use cases: bottom-up approach

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.
Fig. 4

L2 project in Marseille, FRANCE, connecting two highways called A50 and A7

Table 5

The important elements considered in the three use cases


Use cases

Considered elements

Acoustic studies

Safety audit









Level of detail of used information












Some description elements are given bellow:
  1. 1.

    Acoustic studies are about the noise impact of the new infrastructure that will be built. The workflow and processes of this study are considered, defining Unified Modeling Language (UML) use case diagram (different from the use cases described above) (Fig. 5). It allows identifying the environment of the system and the needs of stakeholders (how they use or constrain the system). Then the objects identification and description has been considered to examine how the 3D objects are modified (geometry, attributes, metadata) mainly because of tools.

  2. 2.

    Safety audit is to verify that the designed project meets security requirements. It starts with the identification of the requirements which are numerous and then it defined needs about 3D objects, at which system they belong to and needs about the relevant information detail that has to be modeled in a digital mockup.

  3. 3.

    Drainage: only the longitudinal drainage has been considered. It is an important issue to ensure that the water is properly evacuated from the platform. This study started with the objects identification and description and then with identification of what requirement and systems they are related to.

Fig. 5

Example of UML use case diagram

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.

Used formalisms

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).
Fig. 6

On the left hand side, proposed SADT diagram with UML and PERCEPTORY pictogram (MINnD UC 6-1 2016; Tolmer 2016), presented on the right hand side, extracted from Larrivée et al., (2005). The question mark means that the dimensionality is not defined


Analyze of existing definitions of the concept of level of detail of used information

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.

Applying system engineering and requirement engineering on design project

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.
Fig. 7

Differentiation for the product-system between the whole project and the design project

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.
Fig. 8

Application of system engineering on the product-system product of the project-system

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.

Results for the use case for acoustic studies

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.
Fig. 9

On the left hand side, proposed application of system engineering (Fiorèse and Meinadier 2012) and on the right hand side our adapted proposition based on acoustic studies use case

Fig. 10

3D modeling of acoustic study results with different colors, based on the different levels of noise (green to red). Egis

Fig. 11

Summary of elements about noise barrier workflow during the sizing process. CadnaA is the tool for acoustic studies

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.

Results for the use case for safety audit

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).
Fig. 12

Extract of digital mockup for safety audit. L2 Project, Marseille, FRANCE, Egis

Fig. 13

Relations between the 3D object Security concrete barrier and Systems, Functional structures and requirements

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):
  1. 1.

    identifying the semantic (based on requirements identification),

  2. 2.

    making abstraction to transform this semantic in objects and systems (or functional structure, sum of systems),

  3. 3.

    choosing the relevant standards to exchange information (the LOD and LOI allow to precise the relevant information for this BIM use).

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).
Table 6

Comparison between existing Levels Of Detail and our proposed definition of LOX (LOD, LOI, LOA), regarding the six dimensions proposed by Biljecki et al. (2014)

Table 7

Needed 3D objects and relevant information to solve the requirement SC – 9. This requirement asks if the project geometry minimize the number of obstacles and their dangerousness (columns of this table are partly based on the proposed decomposition of CityGML LOD by Biljecki et al. (2014)

Requirement SC 9




3D Object



geometrical complexity


pavement (current section)


idem conception

black (only to understand the visual scene) and white for marking

safety barrier


design lines

differenciation based on material

directional sign post

station accuracy

conception level

to understand the scene

bridge pier



to understand the scene

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.

Results for the use case for sizing drainage system

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.
Table 8

Part of applying requirement engineering on longitudinal drainage system

External system

Operational requirement

Related system or object


The natural watershed must not receive the waters of the longitudinal network whatever the conditions of rainfall, up to centenale

Longitudinal drainage system

Functional vision (functions and systems)

Related system or object

The longitudinal drainage system must be able to carry a flow for Q25

Longitudinal drainage system

Organic vision (physical architecture)

Related system or object

The longitudinal drainage network must consist of a pipe that allows flow Q25

Piping (part of longitudinal drainage system)

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.
Table 9

Details in information for object modeling, depending on product requirements

Operational requirement: The natural watershed must not receive the waters of the longitudinal network whatever the conditions of rainfall, up to centenale





pipe and other elements of longitudinal drainage system

Membership system

Topological synoptic with connections to retention ponds

retention pond

Name, number

Topological synoptic

Organic requirement: The longitudinal drainage network must consist of a pipe that allows flow Q25







3D object to design diameter and tilt

retention pond

Name, number, volume, type

2 or 3D representation to design volume, type and operation

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.

Discussion and conclusion

Experts in Egis, working for several years in infrastructure project design, confirm that through these three uses cases, this work cover a large part of the objects composing an infrastructure project (safety, drainage and environmental impact). However, the conclusions bellows have to be validated with more use cases. In fact, there is no evidence that the sum of all the use cases of a project is sufficient to describe all the LOX of all the BIM uses.

Defining these three complementary use cases, we describe a significant part of the product-system for design. We have important elements to define almost three BIM uses and their IDM to answer project operational requirements: acoustic regulation, safety requirement and sizing longitudinal drainage system. Other BIM uses have to be considered to answer other operational requirements and to examine other objects. Thus, it will therefore be possible to evaluate the global conceptual project data model to make relevant the objects, project and requirements modeling. However, it is not necessary to consider all use cases of a project to use BIM in an efficient way. Using requirement engineering as proposed allows identifying critical requirements that have to be considered in a BIM way.

As outlined especially in the drainage use case, these IDM elements has to be implement in existing software to verify that they are able to exchange all this information, according to defined needs, supporter by open BIM standards, mainly IFC (for building but also for road, bridge, alignment or tunnels, currently being finalized) and CityGML. The acoustic studies use case shows typical interoperability problems and loosed information through exchanges and object transformations (MINnD UC 6-1 2016). It allowed to identify these elements and seems to be a relevant approach for several BIM uses of different trades (Tolmer 2016).

Then, we detailed the Level Of Detail concept. We can conclude that existing definitions of LOD, LODt or CityGML LOD are not useful in the context in which we use the concept of level of detail of the information. We show that the question of abstraction (which object has to be modeled or exchanged) is implicitly included in actual LOD definitions. It does not allows to identify relevant information according to product requirements and consequently to BIM uses. Based on this uses cases and the MINnD research project, we propose a combination and redefinition of LOD, LOI, introducing the LOA concept mentioned above. It is the first step to define objects modeling in a proper way. It is also the way to introduce ontologies in our conceptual data model proposal. However, we think that organizing abstraction in levels is not fully relevant. How to say which LOA is more (or less) abstraction than another? It seems to be possible to keep the term of level but without the idea to classify them and to give them numbers. We propose to extend this conclusion to LOD and LOI. Is an object with no geometrical information but with a lot of non-geometrical information more detailed than an object with no non-geometrical information but with a lot of geometrical information? Dimensions defined above to explain concepts included in level of detail of the information have to be explicitly independent.

Then, we summarize the results the top-down approach modified by the bottom-up approach. It shows how the concepts and tools of the paradigm of abstract design benefits to the product-system and to the project-system (Fig. 14). The project-system is the first step for using system and requirement engineering to help to structure information that describe the product-system. Use case definition, and consequently BIM use, LOX and requirements definition influence the project-system. Requirement engineering and system engineering both benefit to the product-system through the project-system. It is not possible to use requirement engineering to structure the product-system without considering system and requirement engineering in the project processes (project-system). It has been demonstrated in our experiments on L2 project in Marseille. This proves the fact that the BIM is first processes and data management and not 3D digital mockup only. But our work has shown that this approach has to be tested in more detailed uses cases and especially on a larger part in a project.
Fig. 14

The system engineering benefits to the construction project

We have to explore others BIM uses that have interfaces with drainage design. Using system engineering should help us to select the relevant requirements to treat it entirely. Coherence in the final conceptual data model will be supplied by the definition of several use cases, covering all the scope of design project needs but also using standardize formalisms (Unified Modeling Language (UML), Business Process Modeling Notation (BPMN, used to provide the capability of understanding internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner1) or Structured Analysis and Design Technic (SADT) for example) and open standards as prescribe by the Model Based Design approach, close to the System engineering. Our proposition, based on system and requirement engineering has to be experienced with other use cases. We treated here only requirements related to the design phase. But it is also possible to consider construction and in operation phases. In addition, as defined in system engineering, our proposition can be apply to the project-system and not only on product-system has we have just done in our early work. In this way, it will be possible to consider process requirements and not only product requirements. This will allow to entirely describing BIM uses content. We identify the main elements of the design product-system. The next step of our work should be to verify that the elements considered in each use case are consistent to describe the whole product-system of the whole project.

Finally, system and requirements engineering seem to be new in construction industry. This tools and methods have to be adapted to our profession. Our profession has also to improve its skills on this subject, in addition to changes, introduced by BIM. Thus, we should prove that this approach allow to treat needs and requirements without missing any. It also has to be combined with standards that make link between objects, workflows, meta-data and requirements as PLCS (Product Life Cycle Support) (Tarandi 2011; Zhang et al. 2013). It seems to be a sturdy standard to manage information around objects and requirements, identified as a relevant way to reach project needs and use BIM in a more efficient way.



BIM Execution Plan


Building Information Modeling


Business Process Modeling Notation

CEN/TC 442/WG 2/TG 1: 

European Committee for Standardization/Technical Committee 442/Working Group 2/Task Group 1


Information Delivery Manual


Level Of Abstraction


Level Of Detail, or Development, or Definition


Level of Development


Level Of Information


INteroperable INformation Modeling for sustainable INfrastructures


Structured Analysis and Design Technique


Unified Modeling Language



The author of this paper would like to thank contributors who participated in this different use cases through MINnD research project and BIM development project in Egis called BIM by Egis.


This study has been financed by Egis and to a lesser extent by the French government.

Availability of data and materials

Data are not shared. They are protected by industrial secrecy. Only some digital mockup can be shared: they are the modeling of the original data.

Authors’ contributions

TC-E: This paper is based on the doctoral work and the recent experimentations in Egis of this author; Writing the paper. CC: Supervised the doctoral work partially presented in this paper; Made substantial contributions and analysis of data; Involved in drafting the manuscript or revising it critically for important intellectual content; Gave final approval of the version to be published. YD: Supervised the doctoral work partially presented in this paper; Made substantial contributions and analysis of data; Involved in drafting the manuscript or revising it critically for important intellectual content; Gave final approval of the version to be published. DM: Supervised the doctoral work partially presented in this paper; Gave final approval of the version to be published. All authors read and approved the final manuscript.

Ethics approval and consent to participate

Not applicable.

Consent for publication

Not applicable.

Competing interests

None of the authors have any competing interests in the manuscript. Two authors participate to the L2 project, base of the described experiments.

Publisher’s Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (, which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Authors’ Affiliations

Department of Urban Engineering, Paris Est Marne-la-Vallée University
Project management department, Egis
EIVP; Lab’Urba Department of Urban Engineering, Paris Est Marne La Vallée University


  1. Badreau, S, & Boulanger, J-L (2014). Ingénierie des exigences. Méthodes et bonnes pratiques pour construire et maintenir un référentiel. Paris: Dunod.Google Scholar
  2. Bédard, Y. (1999). Visual modelling of spatial database: toward spatial PVL and UML. Geomatica, 53(2), 169–186.Google Scholar
  3. Biljecki, F, Ledoux, H, Stoter, J, Zhao, J. (2014). Formalisation of the level of detail in 3D city modelling. Computers, Environment and Urban Systems, 48. doi:10.1016/j.compenvurbsys.2014.05.004.
  4. BIMForum. (2016). Level of development specification.Google Scholar
  5. BIMProtocol. (2013). BIM protocol. Standard Protocol for use in projects using Building Information Models.Google Scholar
  6. Bolpagni, M, & Ciribini, A (2016). The information modeling and the progression of data-driven projects. In CIB world building congress, (pp. 296–307) Tampere, Finlande.Google Scholar
  7. Borrmann, A, Ji, Y, Jubierre, JR, Flurl, M (2012). Procedural modeling: A new approach to multi-scale design in infrastructure projects. In EG ICE workshop on intelligent computing in civil engineering.Google Scholar
  8. Bot, L., & Vitali, M.-L. (2011). Modélisation et activités des ingénieurs. (L’Harmattan, Ed.).Google Scholar
  9. Boton, C, Kubicki, S, Halin, G (2015). 4D / BIM simulation for pre-construction and construction scheduling. Multiple levels of development within a single case study. In Creative construction conference Krakow, Poland.Google Scholar
  10. Bouzeghoub, M (2006). Les bases de données et l’IDM. In L’ingénierie dirigée par les modèles, Au delà du MDA (Lavoisier.)Google Scholar
  11. buildingSMART. (2014). IDM definition. Retrieved 8 Jan 2014, from
  12. buildingSMART. (2017). The pillars of standardized and open BIM (non-owner). Retrieved 4 Feb 2017, from Google Scholar
  13. CityGML standard. (2012). Open geospatial consortium OGC City geography markup language (CityGML) encoding standard.Google Scholar
  14. Communic Deliverables. (2010). Communic deliverables. Retrieved 1 Apr 2017, from Google Scholar
  15. Fiorèse, S., & Meinadier, J.-P. (2012). Découvrir et comprendre l’ingénierie système (Cépaduès.). Collection AFIS (Associations Française d’Ingénierie Système).Google Scholar
  16. Fox, K., Morton, B., & Ramos, J. (2013). The business value of BIM for construction in major global markets. Retrieved from Google Scholar
  17. Groger, G, & Plumer, L. (2012). CityGML – Interoperable semantic 3D city models. ISPRS Journal of Photogrammetry and Remote Sensing, 71, 12–33. doi:10.1016/j.isprsjprs.2012.04.004.View ArticleGoogle Scholar
  18. Hascoët, M., & Beaudouin-Lafon, M. (2001). Visualisation interactive d’information. CEPAD.Google Scholar
  19. INCOSE (2015). INCOSE systems engineering handbook: A guide for system life cycle processes and activities, (4th ed., ).Google Scholar
  20. ISO 29481-1:2016. (2016). Building information models - information delivery manual.Google Scholar
  21. ISO 29481-2. (2012). ISO 29481–2 2012 building information modeling - Informations delivery manual part 2: Interaction framework.Google Scholar
  22. Kotonya, G, & Sommerville, I (1998). Requirements engineering: Processes and techniques. Wiley. ISBN: 978-0-471-97208-2.Google Scholar
  23. Kreider, R, & Messner, J (2013). The uses of BIM: Classifying and selecting BIM uses. University Park: The Pennsylvania State University Retrieved from Scholar
  24. Kreider, R., & Messner, J. (2015). A model use ontology. In CIB W78. Eindhoven, Pays-Bas.Google Scholar
  25. Krob, D. (2009). Eléments d’architecture des systèmes complexes in Gestion de la complexité et de l'information dans les grands systèmes critiques.Google Scholar
  26. Larrivée, S, Bédard, Y, Pouliot, J. (2005). How to Enrich the Semantics of Geospatial Databases by Properly Expressing 3D Objects in a Conceptual Model in OTM Workshops, Berlin Heidelberg. pp. 999–1008. ISBN 978-3-540-29739-0.Google Scholar
  27. Lee, S-H, & Kim, B-G (2011). IFC extension for road structures and digital modeling. In The twelfth East Asia-Pacific conference on structural engineering and construction, (vol. 14). Elsevier B.V. doi:10.1016/j.proeng.2011.07.130.
  28. Lowner, M, Benner, J, Groger, G, Hafele, K-H (2013). New concepts for structuring 3D city models – An extended level of detail concept for CityGML buildings, (pp. 466–480). Heidelberg: Springer.Google Scholar
  29. MINnD. (2014). Projet National MINnD : Modélisation des INformations INteropérables pour les INfrastructures Durables.Google Scholar
  30. MINnD. (2017). MINnD Main page. Retrieved 1 Apr 2017, from Google Scholar
  31. MINnD UC 6-1 (2016). Infrastructures et bruit. In Livrable MINnD UC 6.Google Scholar
  32. MINnD UC-3 (2016). State of the art and missing concepts, data dictionary, lifecycle view IDM (information delivery manual). In Livrables MINnD UC 3.Google Scholar
  33. NF ISO 10006. (1998). Management de la qualité : Lignes directrices pour la qualité en management de projet.Google Scholar
  34. Nugroho, A, & Chaudron, MRV. (2009). Evaluating the impact of UML modeling on software Quality : An industrial case study. Model Driven Engineering Languages and Systems, 5795, 181–195.View ArticleGoogle Scholar
  35. Obergriesser, M, & Borrmann, A (2012). Infrastructural BIM standards – Development of an information delivery manual for the geotechnical infrastructural design and analysis process. In eWork and eBusiness in architecture, engineering and construction, (pp. 581–587). London: Taylor & F.View ArticleGoogle Scholar
  36. PAS 1192-2. (2013). Specification for information management for the capital / delivery phase of construction projects using building information modelling.Google Scholar
  37. Penn State. (2011). Building information modeling project execution planning guide. Retrieved from Google Scholar
  38. Plume, J, & Mitchell, J (2011). An urban information framework to support planning decision-making and urban design. In P Leclereq, A Heylighen, G Martin (Eds.), 14th international conference on computer aided architectural design, (pp. 653–666). Belgium: University of Liège Designing Together CAAD Futures.Google Scholar
  39. Ruas, A (2004). Le changement de niveau de détail dans la représentation de l’information géographique. Université de Marne la Vallée. Paris Est Marne-La-Vallée.Google Scholar
  40. Tarandi, V (2011). The BIM collaboration hub: A model server based on IFC and PLCS for virtual Enterprise collaboration. In CIB W78-W102, (pp. 951–960) Sophia Antipolis, France. Digital library of construction informatics and information technology in civil engineering and construction. doi:urn:nbn:se:kth:diva-59918,
  41. Tolmer, C. (2016). Contribution à la mise en place d’un modèle d’ingénierie concourante pour les projets de conception d’infrastructures linéaires urbaines : prise en compte des interactions entre enjeux, acteurs, échelles et objets. Paris Est Marne-La-Vallée, Lab’Urba, Equipe Génie Urbain.Google Scholar
  42. Tolmer, C, Castaing, C, Morand, D, Diab, Y (2015). Information management for linear infrastructure projects: Conceptual model integrating level of detail and level of development. In 32nd CIB W78 conference Eindhoven, Pays-Bas.Google Scholar
  43. Tolmer, C-E, & Castaing, C (2017). Applying system and requirement engineering for information modeling in infrastructure projects. In Proc. Lean & Computing in construction congress (LC3) Heraklion, Greece.Google Scholar
  44. Tolmer, C-E, & Ribeiro, R. (2017). The use of BIM in dispute avoidance: From design to operation. Dispute Review Board, 22(2), 16–21.Google Scholar
  45. Yabuki, N, & Li, Z (2006). Development of new IFC-BRIDGE data model and a concrete bridge design system using multi-agents. In Intelligent data engineering and automated learning – IDEAL 2006, (pp. 1259–1266). Berlin Heidelberg: Springer. doi:10.1007/11875581_149.View ArticleGoogle Scholar
  46. Zhang, C, Beetz, J, Vries, D (2013). Towards model view definition on semantic level: A state of the art review. In Proceedings of European Group for Intelligent Computing in Engineering (EG-ICE ).Google Scholar


© The Author(s). 2017