Extending the IFC Standard to Enable Road Operation and Maintenance Management through OpenBIM

: Open Building Information Modelling (OpenBIM) is a collaborative project management process. Its application to road infrastructures is currently limited. OpenBIM standards for infrastructure are still under development. One of these standards is the Industry Foundation Classes (IFC), which is a data architecture for modelling infrastructure projects. The current and upcoming releases of IFCRoad focus on structuring data for the design and construction phases of an infrastructure’s lifecycle. Semantics of the O&M process phase are not fully integrated within these standards. This paper proposes an extension of the IFC schema to enrich this standard with semantics inherent in the O&M phase of road infrastructures. This extension, based on IFCInfra4OM ontology, allows the OpenBIM process to be fully applied to road infrastructures. Its implementation on a case study relative to the A7 Agadir–Marrakech Highway in Morocco enables, on the one hand, analysis and compliance with O&M management requirements on the basis of a single container: the IFC-BIM-based model. On the other hand, it allows comparison of the OpenBIM process with that of ClosedBIM for the integration of O&M data into BIM for a road infrastructure.


Introduction
Building Information Modelling (BIM) for transport infrastructures enables the optimisation of their lifecycle management [1].The application of BIM for these infrastructures is an initiative of BuildingSmart [2] within the framework of its project IFCInfra [3].This organisation is developing OpenBIM standards to allow constant use of infrastructure data throughout the infrastructure's lifecycle without deploying additional data collection efforts [4].
Unlike ClosedBIM, OpenBIM is a process of exchanging and sharing data [5].While the first is characterised by using proprietary software considered as "black boxes" in terms of processes and data structure, the second allows transparent and sustainable data exchange since it is based on standards [6,7].This is an advantage of OpenBIM, because it guarantees the interoperability of data exchange between the stakeholders of a project, regardless of the software used.
In this context, several OpenBIM standards have been developed by BuildingSmart in order to allow smooth, consistent, interoperable and lossless data exchanges [8].These standards are IFCAlignment [9], for common alignments between infrastructures, such as longitudinal sections and cross sections; IFCBridge [10], for bridge structures; IFCRoad, for road infrastructures [11]; IFCRail [12], for railways; and IFCTunnel, [13] for tunnels.These standards represent an extension of the IFC standard [14].In the future, they will enable the production of a global IFC schema for infrastructures called IFCInfra [15].
ISPRS Int.J. Geo-Inf.2021, 10, 496 2 of 27 BIM is not yet fully applied to the management of road infrastructures.On the one hand, the OpenBIM process is not yet relevant to these infrastructures, as the IFCRoad standard is currently under development [16].On the other hand, the application of ClosedBIM mainly concerns design and construction phases [17].
The operation and maintenance (O&M) phase is the longest in a road's lifecycle [18].It is estimated at 70 to 80% of the costs generated by an infrastructure during its entire lifecycle [19].Additionally, the management of this phase for roads is complex [20] because of its intrinsic components: meteorological and geotechnical conditions, the characteristics of its environment (lithosphere, topography nature, type of vegetation, etc. . . .), its anthropogenic conditions (type of equipment installed, type of road, nature of traffic, etc. . . . ) and its hydro-spherical conditions.However, good management of this phase guarantees optimal functioning of the road and preserves its estimated lifespan [21].
The standardisation of OpenBIM to manage the O&M phase, for road infrastructures, helps optimise this phase in terms of time and costs [22,23].This standardisation begins with the development of IFCRoad.This data architecture enables modelling road components for design and construction requirements.However, this standard does not fully include the business process for managing O&M [17,24].
This paper proposes an extension of the IFC standard to allow for the management of O&M for road infrastructures through OpenBIM.This extension is based on an ontology called 'IFCInfra4OM', developed in a previous work by the same authors [25].This extension aims to model the data resulting from an O&M business process for road infrastructures.The implementation of this extension is illustrated in a case study of a Moroccan highway section.Furthermore, the comparison of O&M management in both OpenBIM and ClosedBIM processes of the same highway section is presented.
In our previous work [25], an ontology called 'IFCInfra4OM' has been developed to define the concepts and the process of O&M.The current paper aims to fill the gaps identified by the literature review.Particularly, the IFC extension developed within the framework of this paper enhances the IFC capabilities to integrate O&M processes and information for road infrastructures.It enables a full management of the O&M phase for these infrastructures, which optimizes the cost and time that can be spent along the lifecycle phases of road infrastructures.The contribution of this paper can be summarised as follows: (1) investigating the possible methods to carry out an extension of the IFC following the recommendations of BuildingSmart and existing research works; (2) enriching the IFC standard with new concepts, relations and properties that improve O&M management for road infrastructures through this standard; (3) applying this extension to a real road infrastructure project to illustrate the added values of the extension in the O&M phase; and (4) carrying out a comparative study between OpenBIM and ClosedBIM approaches for the management of O&M by IFC extension.This comparison highlights the advantages of OpenBIM-based management of road infrastructures.
The paper is organized as follows: Section 2 presents a literature review that frames the research work.Section 3 details the materials and methodology applied to extend the IFC standard based on IFCInfra4OM ontology.Section 4 presents the results obtained.They include the IFC extension data model and the implementation of this extension through a case study.Section 5 discusses the results in the light of the literature review and presents a comparative study between an OpenBIM process, based on IFCInfra4OM ontology, and a ClosedBIM process, applied through proprietary software.

Literature Review
The IFC standard is a data architecture and interchange format for BIM.It is defined according to the ISO 16739-1:2018 standard [26].It enables interoperable sharing of data between project stakeholders throughout the lifecycle of an infrastructure.This standard is currently at version 4.3 [27].It provides a baseline for civil engineering to be extended in future IFC releases.This baseline concerns, among others, the domain of O&M [28].
The technical committees of BuildingSmart [29] conduct the extension of IFC.Their work aims to extend the application of OpenBIM through IFC standards to involve the infrastructure sector.Consequently, for each type of infrastructure, a new extension will be developed.Table 1 summarizes the development progress for each extension currently in the process of being implemented.Validating the standard schema Support data exchange and use cases in the railway industry [32].
It is to be noticed from Table 1 that the only official version of the IFC schema is 4.1, called IFCAlignment.For the IFCRoad version, it is in the technical implementation phase on proprietary software for its last validation.Regarding the next version, IFC 4.3, it is in the phase of the conceptual data schema proposal and pending its final validation.For bridge and railway infrastructures, their IFC standards are still under development.
This section studies the information contained in the current schema of the IFC standard.It also describes the IFCRoad schema which is under development by BuildingSmart.Additionally, it presents the guidelines to be followed for the extension of the IFC standards.

OandM Information Modelling Capabilities of the IFC Standard
The IFC standard is currently undergoing prompt development.The emergence of several successive versions in a short period of time [27] allows this schema to increasingly adjust the requirements of infrastructures in terms of information.However, the management of an infrastructure is not limited to its design or construction phases, it also extends to its operating one.
Particularly for O&M, the current IFC standard does not enable complete management of the operational phase of an infrastructure [17,33].This gap is explained, on the one hand, by the fact that the development of IFC for infrastructures is at its embryonal stage.This limits IFC to objects, which are essential for the design and construction phases, that shape infrastructures.On the other hand, IFC's developments for infrastructure are driven by the extension of IFC version 2.3 with new schemas for infrastructure objects [34,35].However, IFC 2.3 is not fully adopted to the management of O&M because, for example, it excludes interactions between actors and space management programs [36].
The modelling of business processes, concerning the management of O&M, in the IFC schema, is an essential step to allow proper management of this phase for road infrastructures.It increases the capabilities of the BIM model to allow multi-criteria queries that depend on the interactions between actors, systems and processes.
The IFCProcess superclass encompasses a set of concepts useful for managing O&M.It defines, as sub-classes, the entities IFCTask, IFCProcedure and IFCEvent.The IFCProces-sExtension package describes several relations that link these entities.In an O&M process, and as illustrated by the IFCInfra4OM ontology detailed in the following sections, the types of relations required should connect: (1) operations; (2) operations and documents; (3) operations and their positioning on the road; (4) operations and components of a road; and (5) actors on the one hand, and road operations and components on the other.The current IFC schema represents some of these connections, but it remains limited in term of (1) geolocating operations on a specific position on a road alignment and (2) linking tasks or procedures to actors.Table 2 summarizes IFC's capabilities in modelling business relations for the O&M process.These capabilities are extracted from the IFC schema definitions [28].The IFC Entity 1 column shows the name of an IFC class.The IFC Entity 2 column presents another IFC class related to Entity 1.To allow a task, procedure or event to be geo-located on a road alignment.
The information attached to the entities are descriptions that provide sufficient clarification about each concept's class.At the IFC level, this information is presented as attributes or as a set of properties relating to each class.In Table 3, examples of information are given to describe IFC capabilities to model information useful to O&M management.Furthermore, BIM is currently concerned with data inside an infrastructure, while O&M requires knowledge of data outside the infrastructure that relies on the network to which it is connected [37].Integrating this external data into the IFC schema will therefore optimise O&M management.
A few research projects are conducted to apply OpenBIM in the field of O&M for infrastructure in general and road infrastructures in particular [38,39].Examples of these projects are given in Table 4.

Research Work Application Description
[40] Tunnel An IFC based E-platform is used to improve maintenance efficiency and costs' estimation of various maintenance types of a tunnel.
[41] Bridge A BIM maintenance standard for bridges is applied by integrating IFC within a maintenance system to record damages and inspection data.
[42] Bridge An as-built IFC approach is developed to detect and analyse damages on a bridge infrastructure.
[16] Highway An IFC extension is presented to capture description and behaviour of some object-oriented components of a highway to target an effective Asset Management of this type of infrastructure.[43] Road An integrated Asset Management system for roads is presented.It is based on IFC model association with other external data sources to enable several maintenance management aspects such as traffic diversion and simulation, asset condition management and lifecycle monitoring.
It should be noted that the existing works in the literature present, in most instances, the BIM applications as approaches that are mainly concerned with linking IFC to external databases through several systems or proprietary software [44].However, using an intermediate tool such as databases to link additional O&M information to IFC can lead to an important loss of semantic data during the mapping process [45].

The Upcoming IFCRoad Standard
The IFCRoad standard is part of the BIM standardisation projects for all infrastructure project domains [34].Its development is an extension of the IFC schema based on the results of the IFCAlignment and IFCBridge standards developments [34,46].The IFCRoad is produced by BuildingSmart InfraRoom teams.It is currently in its validation stage through its implementation on software [47].The IFCRoad standard presents the base standard to apply OpenBIM to the domain of road infrastructures.
Since 2015, IFCRoad has been in production to address the problems of applying standardised BIM to the modelling of road infrastructures by IFC.These issues relate to: (1) IFC's inadequacy to model road objects; (2) IFC's non-support of spatial elements intrinsic to roads such as cross sections and longitudinal sections; and (3) the absence of a semantic representation of the coordinate systems diversity that exists in the infrastructure domain.
Several efforts have been made to partially resolve these issues.The study of [48] showed the limits of the IFC to model infrastructure products.It proposed an extension of IFC to integrate roads into the IFC schema by introducing new spatial elements and physical components of roads.Additionally, study [49] proposed an OpenBIM approach to model the physical components of a highway.This approach is a data model which allowed for the optimisation of the analyses conducted for the programming and the simulation of a highway construction.Then, through the geometric representation of road alignments, the study [34] proposed a data model to represent its alignments and then integrate them into the overall IFC schema.Study [50] demonstrated how these alignments can be improved to meet a need for design control requirement.It has developed an automated control tool and an export tool for geometry and related information.Finally, the research in [51] allowed the IFC to be analysed in terms of a semantic representation of coordinate reference systems.It also proposed an extension of IFC to incorporate the specifics of such systems into an infrastructure project.
The objective of IFCRoad is to integrate all the requirements needed to enable road information modelling [15].Through this model, the following elements will be geometrically and spatially represented [52]: (1) linear road types; (2) junction types; (3) road components, elements and equipment; (4) positioning elements; and (5) road systems.Along with IFCRoad, a common schema across infrastructure domains, which will include earthwork cut and fill designs as well as geotechnical investigations and constructions, is being developed [53].
This research workpaper proposes examinations of both the current version of the IFC (IFC 4.3) [28] and the upcoming IFCRoad.This analysis indicates that, on the one hand, the current IFC schema is limited for the geometric and semantic representation of infrastructure elements.This representation is essential for the design and construction phases management of an infrastructure.On the other hand, the O&M information contained in IFC 4.3 is more advanced than in earlier versions, but the business process for managing O&M is still not complete within the IFC schema.This brings us to the central question of this paper: "How to allow the IFC standard to model the O&M business process specific to road infrastructures while respecting the content of the current IFC4.3 and the upcoming IFCRoad schemata?"

IFC Extension
This paper considers an extension of the IFC as a major premise.This extension makes it possible to enrich this standard schema with new semantics that address the issues raised in the central question of this paper.
The extension of the IFC can be done through three mechanisms [54][55][56][57]: (1) adding additional information as entity's property sets; (2) grouping additional concepts into proxy elements; or (3) adding new defined concepts by enriching the schema with new entities.
The property sets are sets of attributes that describe an entity object [58].Proxy elements are unspecified entities that depend on their superclasses, in the IFC schema, from which they inherit their functionality [59].Property sets and proxy elements allow additional information to be added without extending the schema.However, the use of property sets just allows the inclusion of new information that better describe the elements to which they are attached [56].In different circumstances, using proxy elements only allow adding new entity types [56].
The use of property sets and proxy elements is limited in terms of enriching IFC.They are ambiguous, error-prone and not suitable for a semantically well-defined description of non-standard IFC objects [57].Further, the integration of a business process specific to O&M information will have to go through the addition of new entities and new relations within the IFC schema to optimize the management of this phase for road projects.
However, to achieve an extension of the IFC schema, BuildingSmart has set up guidelines to preserve the universality of the IFC standard and the homogeneity of its versions [15].These guidelines are as follows: (1) the identification of the closest concept should be done for every new concept considered for the extension; (2) similar concepts should be considered according to their functionalities, not their use domain; (3) the international use of IFC data model functionalities should be separated from local extensions; (4) to integrate national specificities in the IFC schema, the BIM model can be linked to an Object Type Library (OTL) [60]; and (5) to link external systems to IFC schema, Semantic Web Technologies can be used.
The following sections of this paper answer the research question by tackling the issue of modelling information relating to the O&M of a road infrastructure through the IFC schema.The proposed methodology aims to extend the IFC standard to include new entities and relations while respecting OpenBIM guidelines.

Materials
The IFC extension proposed in this paper is based on two data models: (1) an ontology data model called IFCInfra4OM, defined in previous research [25] and presented in the results section, and (2) the IFC 4.3 data model, which is the latest IFC version proposed by BuildingSmart [27].
The IFCInfra4OM is an ontology based on two domains of knowledge.The first domain is BIM and the second one concerns O&M for road infrastructures [25].This ontology is presented to put forward a new approach, to integrate BIM for managing the O&M phase for road infrastructures.Following a thorough definition of this ontology, a data model is established to model the semantics of O&M according to the business process of managing this phase for road infrastructures.
This data model has 3 semantic levels: (1) operation, (2) monitoring and (3) actors.The class diagram of the concepts defined is presented in Figure 1 to provide minute guidance for a better understanding of the IFC schema extension [25].
In addition to operations, documents and actors, IFCInfra4OM ontology incorporates new concepts which are not defined by IFC.These new concepts are essential for the management of the O&M phase for a road infrastructure.They are defined in Table 5.  Recorded by a system such as sensor networks or measuring equipment.The analysis of monitoring data, that has exceeded a regulated threshold, may lead to a detailed inspection in the case where there is a localised measurement, or to an expertise in the case of a measurement over a large area.

Regulatory Threshold
A normalised or standardised technical value of a measure.This value is critical because once a monitoring data exceeds it, a potential risk may occur.
Defined and described in a document.
The IFC standard is an object-oriented file format and data model that structures infrastructure information into a set of attributes that describes the objects' classes that they compose.IFC version 4.3 is an extension of IFC, whose objective is to extend the scope of this standard to the domains of road, port, railway, and waterway infrastructures engineering [30].

Methodology
To extend the IFC standard, several steps are required as described by the diagram in Figure 2. First, a preliminary study is conducted to analyse the IFC schema in terms of semantics specific to O&M, on the one hand, and those relating to road infrastructure, on the other.Second, the data model based on IFCInfra4OM is established.It allows for the studying of the business process of O&M management for road infrastructures.Through this data model, the essential semantics to describe this process are defined and modelled.Third, the IFC extension is proposed.In this step, two aspects are investigated: (1) the different possible mechanisms for expanding IFC.They describe the ways in which new semantics could be added to the IFC schema to allow its extension, and (2) the extension guidelines specified by BuildingSmart.The extension of IFC by IFCInfra4OM ontology is achieved according to 4 packages, each of them containing a different type of semantics: (1) the "Operation" package, containing entities and information relating to maintenance operations; (2) the "Monitoring" package, related to data and monitoring systems; (3) the "Actors" package, corresponding to the actors involved in OandM; and (4) the "Road Components" package, comprising the physical components of a road and its environment.
The data model of the IFC schema extended by the IFCInfra4OM ontology is first carried out according to a UML (Unified Modelling Language) [61] formalisation in a class diagram.This language is adopted for two reasons: (1) to ensure the integration of the IFCInfra4OM concepts, originally developed in UML, within the IFC schema, and (2) to respect the trend of UML developing adopted recently by BuildingSmart [31].In fact, the IFC infrastructure projects, such IFRCRoad, have used UML as their primary tool for information modelling [31,62], and BuildingSmart has announced an upcoming move from EXPRESS to UML as the original modelling language for IFC [63].
The extension is done with reference to IFC semantics regarding O&M information on the one hand and following BuildingSmart guidelines on the other.The mechanisms applied to extend IFC schema with IFCInfra4OM are described in Tables 6 and 7.
guidelines specified by BuildingSmart.The extension of IFC by IFCInfra4OM ontology is achieved according to 4 packages, each of them containing a different type of semantics: (1) the "Operation" package, containing entities and information relating to maintenance operations; (2) the "Monitoring" package, related to data and monitoring systems; (3) the "Actors" package, corresponding to the actors involved in OandM; and (4) the "Road Components" package, comprising the physical components of a road and its environment.In Table 6, a colour code is used to differentiate between the different extension mechanisms.The rows with a light grey colour filling represent concepts found equivalent in the IFC schema and for which no change has been made.The rows with a darker grey colour filling represent IFCInfra4OM concepts for which no equivalence has been found in the IFC schema.For this purpose, a class is newly added to model this concept.The rows in white are those whose equivalent concept found in the IFC schema are represented by a "Type Enumeration".Thereby, a new enumeration is added to the existing list to integrate the concept.In Table 7, the Entity 1 column shows the name of an IFC class.The Entity 2 column presents another IFC class that we propose to link to Entity 1 with the new relation designated in column 3 of the same Table.
After elaborating the UML diagram of the IFC extension data model, the EXPRESS diagram is realised in compliance with the data modelling language used commonly for IFC development and formalized in ISO 10303-21:2016 [64].To develop the EXPRESS diagram, the UML diagram previously realised was imported and processed on the IfcDoc tool [65] developed by BuildingSmart [66].To validate the extension work, two levels of validation are adopted.First, the syntax is validated.Second, the semantics of the new extension schema is validated according to the BuildingSmart guidelines [67].Additionally, in order to validate the application of the proposed IFC extension, the implementation of the data model is done through an Open-BIM process.It was carried out on a section of the Moroccan A7 highway, connecting two cities, Agadir and Marrakech, as a case study.The implementation steps are shown in the diagram in Figure 3.The IFC extension UML diagram is transformed into a physical data model to allow the IFC database tables to be generated.O&M information was extracted from technical documents of the Moroccan Organisation for Highways (ADM) [68][69][70].This organisation fulfils the role of managing Moroccan highways.No external databases were used to retrieve O&M information.This information was extracted from the ADM technical documents and then mapped to the IFC-based model.Geometry data relating to the physical components such as equipment, alignments and the Digital Terrain Model are extracted from a 3D model as triangulated mesh surface geometry.This information and data are then mapped to the database using an ETL (Extract, Transform, Load) process.The Highway Information Model of the studied road segment is consequently produced.The geometric and semantic components of this Highway Information Model are visualised through a 3D viewer.The latter allows loading O&M semantic information and 3D geometry from the database.Finally, this implementation of the IFC extension following the OpenBIM process is presented in contrast to a ClosedBIM.This contrast is highlighted by a comparative study between the two processes.

IFC Extension Results
The results of extending the IFC schema by IFCInfra4OM ontology are as follows: (1) three new object classes, that result from IFCInfra4OM ontology, are added; (2) three

IFC Extension Results
The results of extending the IFC schema by IFCInfra4OM ontology are as follows: (1) three new object classes, that result from IFCInfra4OM ontology, are added; (2) three existing enumerations on the IFC schema are enriched; (3) one enumeration class is added; (4) several relations are defined between IFC classes and the newly added classes; and (5) classes' attributes extracted from IFCInfra4OM are added to IFC existing classes to describe them.These attributes are delineated as six new property sets.They are modelled according to BuildingSmart guidelines that are detailed in [67].
The UML diagrams of the extension are shown in Figure 4a-d.In these diagrams, yellow entities are existing IFC classes.They all begin with the "Ifc" prefix.Pink entities are IFC existing relations.They begin with the "IfcRel" prefix and are modelled in IFC as classes.Enriched enumerations are in brown.The new added enumeration values are framed in red.Relations in thin lines are those that exist in the IFC schema.Green entities are new classes added to extend IFC schema.They are linked to existing classes and property sets through new relations.The latter are represented in thick lines along with their designations.New relations are named in accordance with IFC existing ones, with the prefix "IfcRel".To integrate new property sets, the entity name begins with the "Pset_" prefix.It is linked to a class with a UML "Realise" relation.
An extract from the elaborated EXPRESS diagram is presented in Figure 5.In this diagram, the new classes that were added to the IFC schema are green-framed entities.New relations defined by the IFCInfra4OM ontology are presented as red-framed entities.The new property sets are blue framed.Existing type enumerations that were enriched with concepts from the IFCInfra4OM are brown-framed entities.As the IFC schema was traditionally represented by the EXPRESS diagramming language, the EXPRESS diagram is provided to facilitate the IFC extension adoption.Furthermore, the UML diagram is used to implement the IFC extension on the case study presented in Section 4.2.2.

Results Validation 4.2.1. Semantic and Syntactic Validation
Syntactic validation is done by checking the conformity of the data model with the UML syntax with which the extension schema is established.This validation includes (1) the well-formedness of entities and relations, (2) the element composition validation and (3) property validity.
Semantic validation is carried out through two steps.First, the definition of the IFCInfra4OM ontology concepts is done with the support of experts from the ADM organisation [25].Once the concepts of the ontology and their field of application are technically defined, they were discussed with the experts for their feedback and validation.
Second, the application of the BuildingSmart guidelines to the IFC extension helps optimise the extension of semantics.The result of this validation is illustrated in Table 8.
Table 8.BuildingSmart guidelines application approach to validate the IFC extension.

OpenBIM Guidelines Example of IFCInfra4OM Concept IFC Extension Result
The closest existing concept in the IFC class structure should be identified.Inspection No entity class added.The IFC existing type enumeration called "Diagnostic" of "IFCTask" class is equivalent.
The equivalence is judged according to concept function, not according to the domain where it may be used.
Highway (which is a type of road) An IFCRoad class already exists in IFC to describe road infrastructure.Instead of creating a new class, a new type enumeration class containing "Highway" as a type, is added.
A careful distinction between the functionalities of the international data model and its local extensions is recommended.

Class attributes are defined in the IFCInfra4OM ontology based on a universal criterion
The attributes of equivalent entity classes are added as property sets of these classes.For new added classes, attributes are defined directly on the classes.

Case Study Validation: Implementation
The case study used to implement the extension of the IFC schema is a highway section.This section belongs to the A7 Moroccan highway which links the cities of Agadir and Marrakech.It is located in the mountainous area of the Moroccan Atlas at the geographical location 30 • 59 10.32 N, 9 • 02 28.10 W. It is characterized by several surrounding conditions which require regular monitoring and recurring maintenance operations [71,72].In previous works [25], a ClosedBIM process was applied to this highway section.This application is fulfilled using a proprietary software.It performs a connection between a database containing information of O&M and a three-dimensional model of this highway segment.The result obtained from the application of this ClosedBIM process is illustrated in Figure 6.
In this paper, the OpenBIM approach is adopted.This approach aims to use the BIM model based on the IFC standard as the unique container of O&M information without the need to connect an external database to the BIM model.The OpenBIM approach is based on the IFC extension by the IFCInfra4OM ontology proposed in this paper.Its implementation is realised on a Highway Information Model generated using this IFC extension.First, an IFC database (DB) is produced based on the extension's UML diagram.Then, the DB is packed with information about O&M as well as the geometry relating to the highway components.This integration is done through an ETL mapping procedure.The mapping consists of transforming the data relative to O&M information and geometry to the tables of the IFC DB (see Figure 7).Finally, a three-dimensional viewer is connected to the database to visualise the Highway Information Model and perform analyses on this OpenBIM-based model.Figure 6.ClosedBIM approach application to the O&M of the A7 Moroccan highway segment [25].
In this paper, the OpenBIM approach is adopted.This approach aims to use the BIM model based on the IFC standard as the unique container of O&M information without the need to connect an external database to the BIM model.The OpenBIM approach is based on the IFC extension by the IFCInfra4OM ontology proposed in this paper.Its implementation is realised on a Highway Information Model generated using this IFC extension.First, an IFC database (DB) is produced based on the extension's UML diagram.Then, the DB is packed with information about O&M as well as the geometry relating to the highway components.This integration is done through an ETL mapping procedure.The mapping consists of transforming the data relative to O&M information and geometry to the tables of the IFC DB (see Figure 7).Finally, a three-dimensional viewer is connected to the database to visualise the Highway Information Model and perform analyses on this OpenBIM-based model.
The software used as part of the extension model implementation are: (1) Autodesk Civil 3D [73] and Autodesk Infraworks [74] to enable an extraction of geometric data from the highway 3D model; (2) Enterprise Architect software [75] employed to produce the UML data model and to generate the IFC database tables; (3) FME software [76] to help map geometric and semantic data to the database tables; and (4) FME Data Inspector to visualise the OpenBIM model in three dimensions and to apply several analyses to it.
To guarantee the compatibility between multiple-volume solids that model the highway, its alignments and its equipment, we first extracted the highway and its environment three-dimensional model from the same source (which is the Infraworks Model Builder Database [74]).Then, on Civil 3D [73], further processing was carried out on the model.The highway pavement model, the equipment models, the alignment model and the slope model were extracted separately.Furthermore, the same three-dimensional model type and format were adopted for all the models.The three-dimensional model type is the triangulated mesh, and the format is the ".obj".Finally, the same mapping procedure was carried out to load the highway and its components geometries to the corresponding IFC classes.This last step consists of using the FME "Geometry Extractor" [77] to read the inputs (which are the three-dimensional triangulated surface shapes) and map them to the output's containers (which are the corresponding IFC standard classes) (see Figure 7).An extract from the IFC model generated is presented in Figure 8.This extract is based on the XML language.The extract represents the definition of a task modelled through the "IFCTask" entity that exists in the IFC schema.It is defined by its description, start and end date, start and end points as well as its type.Figure 8 also shows the highway alignment related to this task.The alignment is modelled as an "IFCAlignment" entity.It is geolocated on the Agadir-Marrakech A7 highway, modelled as type "Highway" of the "IFCRoad" entity.The software used as part of the extension model implementation are: (1) Autodesk Civil 3D [73] and Autodesk Infraworks [74] to enable an extraction of geometric data from the highway 3D model; (2) Enterprise Architect software [75] employed to produce the UML data model and to generate the IFC database tables; (3) FME software [76] to help map geometric and semantic data to the database tables; and (4) FME Data Inspector to visualise the OpenBIM model in three dimensions and to apply several analyses to it.
To guarantee the compatibility between multiple-volume solids that model the highway, its alignments and its equipment, we first extracted the highway and its environment three-dimensional model from the same source (which is the Infraworks Model Builder Database [74]).Then, on Civil 3D [73], further processing was carried out on the model.The highway pavement model, the equipment models, the alignment model and the slope model were extracted separately.Furthermore, the same three-dimensional model type and format were adopted for all the models.The three-dimensional model type is the triangulated mesh, and the format is the ".obj".Finally, the same mapping procedure was carried out to load the highway and its components geometries to the corresponding IFC classes.This last step consists of using the FME "Geometry Extractor" [77] to read the inputs (which are the three-dimensional triangulated surface shapes) and map them to the output's containers (which are the corresponding IFC standard classes) (see Figure 7).
An extract from the IFC model generated is presented in Figure 8.This extract is based on the XML language.The extract represents the definition of a task modelled through the "IFCTask" entity that exists in the IFC schema.It is defined by its description, start and end date, start and end points as well as its type.Figure 8 also shows the highway alignment related to this task.The alignment is modelled as an "IFCAlignment" entity.It is geolocated on the Agadir-Marrakech A7 highway, modelled as type "Highway" of the "IFCRoad" entity.An extract from the IFC model generated is presented in Figure 8.This extrac based on the XML language.The extract represents the definition of a task model through the "IFCTask" entity that exists in the IFC schema.It is defined by its descripti start and end date, start and end points as well as its type.Figure 8 also shows the highw alignment related to this task.The alignment is modelled as an "IFCAlignment" entity is geolocated on the Agadir-Marrakech A7 highway, modelled as type "Highway" of "IFCRoad" entity.An example of the three-dimensional visualisation of the road's BIM objects is giv in relation to the "IFCBuiltElement" represented by a dynamic barrier in Figure 9. T highway equipment is installed to retain rocks in case of a rock-fall event.Anoth example is illustrated in Figure 10.It displays an "IFCTask" operation of type a description designated as "Installation" and "installation of a gabion wall at the bott An example of the three-dimensional visualisation of the road's BIM objects is given in relation to the "IFCBuiltElement" represented by a dynamic barrier in Figure 9.This highway equipment is installed to retain rocks in case of a rock-fall event.Another example is illustrated in Figure 10.It displays an "IFCTask" operation of type and description designated as "Installation" and "installation of a gabion wall at the bottom of the South zone", respectively.This operation is georeferenced on the highway segment according to the "IFCAlignment" class.
To analyse O&M information, filters are run on the Highway Information Model.An example of these filters is given in Figure 11.The unique values of the enumerations defined in the data model allow an optimisation of the result of these analyses.For example, Figure 12 illustrates how it is possible to explore O&M information, by criteria of the unique type of operations, through the IFCTask class.In addition, these operations concern "Installation" or "Maintenance" and take place on the A7 highway whose IFCAlignment is codified on the Highway Information Model.The operations are also sorted for a specific period of time.
of the South zone", respectively.This operation is georeferenced on the highway segment according to the "IFCAlignment" class.To analyse O&M information, filters are run on the Highway Information Model.An example of these filters is given in Figure 11.The unique values of the enumerations defined in the data model allow an optimisation of the result of these analyses.For example, Figure 12 illustrates how it is possible to explore O&M information, by criteria of the unique type of operations, through the IFCTask class.In addition, these operations concern "Installation" or "Maintenance" and take place on the A7 highway whose IFCAlignment is codified on the Highway Information Model.The operations are also sorted for a specific period of time. of the South zone", respectively.This operation is georeferenced on the highway segment according to the "IFCAlignment" class.To analyse O&M information, filters are run on the Highway Information Model.An example of these filters is given in Figure 11.The unique values of the enumerations defined in the data model allow an optimisation of the result of these analyses.For example, Figure 12 illustrates how it is possible to explore O&M information, by criteria of the unique type of operations, through the IFCTask class.In addition, these operations concern "Installation" or "Maintenance" and take place on the A7 highway whose IFCAlignment is codified on the Highway Information Model.The operations are also sorted for a specific period of time.

Discussion and Conclusions
This research paper aims to integrate the management of the O&M phase specific to road infrastructure projects using BIM.This integration is conducted through the OpenBIM process by answering the focal research question: "How to allow the IFC standard to model the O&M business process specific to road infrastructures while respecting the content of the current IFC4.3 and the upcoming IFCRoad schemata?".The answer to this question is constrained by issues which are supported by the literature review.Namely: (1) the development of the IFC schema for roads is still underway, which limits the application of OpenBIM to this type of infrastructure; (2) the schema of the upcoming IFCRoad is mainly focused on the components that make the management of the O&M phase through the OpenBIM process embryonal; (3) the insufficiency of the relations between entities, that are part of the O&M process, within the IFC schema; and (4) the IFC schema focuses on the internal data of an infrastructure.External data need to be integrated to understand O&M issues like component failure and decrease of an infrastructure's lifespan.
To answer the research question, the methodology proposed is based first on a detailed analysis of the IFC schema and the upcoming IFCRoad schema.Subsequently, it suggests enriching the IFC 4.3 schema with new semantics.These semantics are extracted from an ontology called IFCInfra4OM.It is developed in the authors' previous research

Discussion and Conclusions
This research paper aims to integrate the management of the O&M phase specific to road infrastructure projects using BIM.This integration is conducted through the OpenBIM process by answering the focal research question: "How to allow the IFC standard to model the O&M business process specific to road infrastructures while respecting the content of the current IFC4.3 and the upcoming IFCRoad schemata?".The answer to this question is constrained by issues which are supported by the literature review.Namely: (1) the development of the IFC schema for roads is still underway, which limits the application of OpenBIM to this type of infrastructure; (2) the schema of the upcoming IFCRoad is mainly focused on the components that make the management of the O&M phase through the OpenBIM process embryonal; (3) the insufficiency of the relations between entities, that are part of the O&M process, within the IFC schema; and (4) the IFC schema focuses on the internal data of an infrastructure.External data need to be integrated to understand O&M issues like component failure and decrease of an infrastructure's lifespan.
To answer the research question, the methodology proposed is based first on a detailed analysis of the IFC schema and the upcoming IFCRoad schema.Subsequently, it suggests enriching the IFC 4.3 schema with new semantics.These semantics are extracted from an ontology called IFCInfra4OM.It is developed in the authors' previous research [25] and contains concepts specific to O&M management for road infrastructures.The IFC extension proposed using the IFCInfra4OM ontology is based on the literature review and the BuildingSmart extension guidelines.
The case study, used to implement the IFC extension, validates the applicability of this extension through three-dimensional visualisation and analysis of O&M data.It has also overcome the limitations of the current IFC to represent O&M information and process.To fill this gap, the enrichment of IFC by IFCInfra4OM semantics-at the level of object classes, object types and relations between objects and object property sets-enhanced the capabilities of IFC to describe and manage the O&M phase for road infrastructures.The added values of this extension are described in Table 9.During a road diagnostic procedure, some data can be acquired-such as laser scanner data or drone data-to inspect an observed hazard on one of the components of the road.This relationship provides information on which procedure acquired these data and the reason behind it.
Enrichment of the type enumeration of the existing class "IFCEvent" Added three new types of road related events.
The events that can trigger an O&M procedure in a road are classified into three types: road component degradation, environmental degradation and road traffic accident.This classification helps optimising preventive actions for O&M.
In parallel, a ClosedBIM process is applied.This process is depicted on the left diagram of Figure 13.The comparison of the two processes, ClosedBIM and OpenBIM, allows for the underlining of the advantages of the latter.The OpenBIM process, which results in the use of the IFC standard, resulted in having a single container of O&M information (which is the IFC-based BIM model).However, in ClosedBIM, several containers (system database and three-dimensional model) are necessary to produce a BIM for O&M information.Additionally, in the ClosedBIM process, the production of the BIM model is strongly influenced by the software and their versions as well as by the access rights to databases.On the one hand, the link between the information contained in a system database and a three-dimensional model can lead to data loss.On the other hand, the application of use cases depends heavily on the ability of software to communicate with each other.This is due to interoperability problems that may arise in a ClosedBIM process.In OpenBIM, the path between the production of the BIM model and the application of different use cases is optimised.Since IFC is the unique container of the O&M semantics and the geometry, the application of a use case is done by the direct exploitation of the BIM model.
in a system database and a three-dimensional model can lead to data loss.On the other hand, the application of use cases depends heavily on the ability of software to communicate with each other.This is due to interoperability problems that may arise in a ClosedBIM process.In OpenBIM, the path between the production of the BIM model and the application of different use cases is optimised.Since IFC is the unique container of the O&M semantics and the geometry, the application of a use case is done by the direct exploitation of the BIM model.The extension of the IFC schema is carried out based on the BuildingSmart guidelines.According to these guidelines, such an exercise will first have to go through the search for concepts equivalent to those that we want to integrate into the IFC schema.However, for the purposes of this research, such concepts are not defined in the IFC schema as separate classes, but as enumerations of types.Examples of these concepts are "Operation", "Maintenance" and "Installation".These IFC concepts are equivalent to the "Operation" concept in the IFCInfra4OM ontology.However, they are modelled in IFC as enumerations of the "IFCTask" class.This constraint means that, just as we cannot enrich these three concepts with the attributes of the "Operation" class of IFCInfra4OM, we are also unable to enrich the IFCTask class too, because it contains other enumeration types that are not relevant to O&M and which may inherit these attributes.To resolve this issue, the attributes are added as property sets linked to classes or superclasses for concepts that are defined as enumeration types.
As a conclusion, the extension of the IFC schema proposed in this paper enables concrete application of OpenBIM to road infrastructures for the management of the O&M phase.For future research, we recommend the creation of an OTL that will contain the concepts of IFCInfra4OM and their attributes.This OTL will then be linked to the IFC extension schema in order to alleviate the problems of adding attributes for binding classes.Furthermore, analysing O&M information contained in IFC-based BIM can be improved by developing new algorithms adapted to the O&M management process.Finally, other use cases of O&M management can be implemented and analysed using the road BIM model produced.The extension of the IFC schema is carried out based on the BuildingSmart guidelines.According to these guidelines, such an exercise will first have to go through the search for concepts equivalent to those that we want to integrate into the IFC schema.However, for the purposes of this research, such concepts are not defined in the IFC schema as separate classes, but as enumerations of types.Examples of these concepts are "Operation", "Maintenance" and "Installation".These IFC concepts are equivalent to the "Operation" concept in the IFCInfra4OM ontology.However, they are modelled in IFC as enumerations of the "IFCTask" class.This constraint means that, just as we cannot enrich these three concepts with the attributes of the "Operation" class of IFCInfra4OM, we are also unable to enrich the IFCTask class too, because it contains other enumeration types that are not relevant to O&M and which may inherit these attributes.To resolve this issue, the attributes are added as property sets linked to classes or superclasses for concepts that are defined as enumeration types.
As a conclusion, the extension of the IFC schema proposed in this paper enables concrete application of OpenBIM to road infrastructures for the management of the O&M phase.For future research, we recommend the creation of an OTL that will contain the concepts of IFCInfra4OM and their attributes.This OTL will then be linked to the IFC extension schema in order to alleviate the problems of adding attributes for binding classes.Furthermore, analysing O&M information contained in IFC-based BIM can be improved by developing new algorithms adapted to the O&M management process.Finally, other use cases of O&M management can be implemented and analysed using the road BIM model produced.
ISPRS Int.J. Geo-Inf.2021, 10, x FOR PEER REVIEW 12 of 29 the BuildingSmart guidelines[67].Additionally, in order to validate the application of the proposed IFC extension, the implementation of the data model is done through an OpenBIM process.It was carried out on a section of the Moroccan A7 highway, connecting two cities, Agadir and Marrakech, as a case study.The implementation steps are shown in the diagram in Figure3.The IFC extension UML diagram is transformed into a physical data model to allow the IFC database tables to be generated.O&M information was extracted from technical documents of the Moroccan Organisation for Highways (ADM)[68][69][70].This organisation fulfils the role of managing Moroccan highways.No external databases were used to retrieve O&M information.This information was extracted from the ADM technical documents and then mapped to the IFC-based model.Geometry data relating to the physical components such as equipment, alignments and the Digital Terrain Model are extracted from a 3D model as triangulated mesh surface geometry.This information and data are then mapped to the database using an ETL (Extract, Transform, Load) process.The Highway Information Model of the studied road segment is consequently produced.The geometric and semantic components of this Highway Information Model are visualised through a 3D viewer.The latter allows loading O&M semantic information and 3D geometry from the database.Finally, this implementation of the IFC extension following the OpenBIM process is presented in contrast to a ClosedBIM.This contrast is highlighted by a comparative study between the two processes.

Figure 5 .
Figure 5. Extract from the EXPRESS diagram of the IFC extension by IFCInfra4OM ontology.

Figure 7 .
Figure 7. Extract from the ETL mapping procedure.

Figure 7 .
Figure 7. Extract from the ETL mapping procedure.

Figure 8 .
Figure 8. XML extract from the IFC model based on the IFC extension.

Figure 8 .
Figure 8. XML extract from the IFC model based on the IFC extension.

Figure 9 .
Figure 9. IFCBuiltElement "Dynamic Barrier" three-dimensional view from the Highway Information Model.

Figure 10 .
Figure 10.O&M information extraction from IFCTask class and its geolocation on the IFCAlignment entity.

Figure 9 .
Figure 9. IFCBuiltElement "Dynamic Barrier" three-dimensional view from the Highway Information Model.

Figure 9 .
Figure 9. IFCBuiltElement "Dynamic Barrier" three-dimensional view from the Highway Information Model.

Figure 10 .
Figure 10.O&M information extraction from IFCTask class and its geolocation on the IFCAlignment entity.

Figure 11 .
Figure 11.Example of analysis filter applied to the Highway Information Model.Figure 11.Example of analysis filter applied to the Highway Information Model.

Figure 11 .
Figure 11.Example of analysis filter applied to the Highway Information Model.

Figure 12 .
Figure 12.Example of the result of the multi-filter queries: IFCTask installation and maintenance type extracted and geolocated on the IFCAlignment.

Figure 12 .
Figure 12.Example of the result of the multi-filter queries: IFCTask installation and maintenance type extracted and geolocated on the IFCAlignment.

Table 1 .
Chronological development of some IFC standards for infrastructure.

Table 2 .
Extract of O&M process modelling capabilities of IFC standard.

Table 3 .
Extract of O&M information modelling capabilities of IFC standard.

Table 4 .
Examples of OpenBIM applications in the field of O&M for infrastructures.

Table 5 .
Description of new IFCInfra4OM concepts to extend IFC schema.

Table 9 .
Examples of IFC extension by IFCInfra4OM-ontology-added values to enhance IFC capabilities to manage O&M phase for road infrastructures.