BIM-Enabled Infrastructure Asset Management Using Information Containers and Semantic Web

Transportation asset management is defined as “a strategic and systematic process of operating, maintaining, upgrading, and expanding physical assets effectively throughout their lifecycle. It focuses on business and engineering practices for resource allocation and utilization, with the objective of better decision making based upon quality information and well defined objectives” (AASHTO 2013). In recent decades, infrastructure owners have moved towards strategic AM, i.e., a systematic approach managing their infrastructure assets to support long-term transportation infrastructure goals and inform investment planning. Owners strive to optimize their limited budgets and resources to adequately plan maintenance activities for assets, thus maximizing the benefit and minimizing the necessity for reactive repairs or asset replacement. Furthermore, transportation agencies are coming under increased pressure to provide more-reliable and safer infrastructure, especially in the light of recent sudden failures such as the collapse of the Polcevera Viaduct in Genoa in 2018 (Calvi et al. 2019). Many infrastructure owners have legacy transportation networks; for example, the rail networks in Ireland (IRRS 2010) and the United Kingdom (UK) (Guler 2013) were constructed in the nineteenth century, prior to the advent of modern engineering standards. In addition, transportation agencies have to handle increasing demand from customers, reduced budgets, and greater challenges to deliver value for money and transparent processes for investments (PIARC 2017). To overcome these challenges, one aim of AM is to align and link processes so that all business units within an agency operate in a coordinated fashion (FHWA 2012). Within the framework of AM, reliable data are needed to obtain information about the current condition of the transportation infrastructure and, based on this, to predict its future state. These data then serve as the basis for the decision-making process on the timing, scope, and costs of maintenance interventions (Hajdin et al. 2019). AMS help to force this decision-making process by supplying results of different case scenarios by comparing several applied maintenance strategies.

AMS for roads and bridges can be viewed as a cornerstone of the broader context of infrastructure asset management (Hajdin et al. 2019). These management systems use the results of data collection processes, prediction models, a set of rules to determine intervention options within maintenance planning, and functionality to generate and evaluate projects and policies (Zimmerman and Ram 2015). There are a variety of different AMS solutions on the market. However, a common AMS consists of inventory, inspection, maintenance, and planning modules (Hajdin et al. 2019). One of the key components of the management of assets is the inventory and documentation related to all relevant assets (OECD 2001). An inventory module includes administrative and technical asset data (e.g., bridge and road IDs, geolocation, bridge type, and so forth) and optional information such as photos of bridge elements or pavements. An inspection module enhances the asset data according to the inspection findings, i.e., ratings of the structural (e.g., deck, piers, and abutments) and nonstructural (e.g., safety rail, pavement, and drainage system) elements. A forecast of condition deterioration is the basis for estimating future maintenance. The final component of an AMS is a planning module that enables the managing agency to determine what maintenance and rehabilitation actions should be taken given the current and predicted conditions of the pavement sections and bridges (Ismail et al. 2009).

BIM for the transportation infrastructure was analyzed extensively by Costin et al. (2018) by reviewing relevant literature to provide insights into the current topics, the state of the art in industry and academia, and future challenges in this domain. They also reviewed application and use cases of BIM in transportation infrastructure, particularly transportation asset management, maintenance, inspection, and data management. Costin et al. found a large number of current research papers on bridge and road infrastructure. Within bridge management, Bridge Information Modeling (BrIM) approaches cover the life-cycle aspects of bridges: planning, design, construction, and maintenance. Considering the use of BIM in pavement design and planning implementation to date has been challenging, and the limitation of the industry foundation classes (IFC) data model and a lack of standards was referred to in several studies. A review of the literature shows that data exchange between infrastructure and BIM still is lacking a standardized neutral exchange format. Thus, ontologies and Semantic Web technologies are an emerging trend to enrich the information with BIM and to increase interoperability among stakeholders. Bazán et al. (2020) examined road and bridge infrastructure management, and presented a set of use cases for optimized and sustainable infrastructure management. In the design phase, BIM is used to a certain extent, but the lack of semantics for geometric elements hinders the efficient use of BIM in successive phases. In use cases, Bazán et al. (2020) noted that due to complexity, lack of appropriate software applications, and missing standardized information exchanges, BIM is not yet implemented widely for maintenance of infrastructure.

In the design and planning phase, the parametric and algorithmic modeling of bridges was considered by Girardet and Boton (2021). They improved the time for generating a 3D BIM model of a bridge is reduced, and the geometric accuracy. Sacks et al. (2018) proposed a BIM-integrated bridge inspection system. Their approach mainly involves capturing and collecting data for bridge inspection using BIM with IFC standards. With the recommended information delivery manual (IDM) as the documentation medium for data exchange and the developed model view definition (MVD) based on the IDM, the required bridge inspection data can be defined and validated using IFC entities and their spatial and semantic relationships.

Vignali et al. (2021) presented a case study of the application of BIM for the design of road segments, including the utilization of three-dimensional (3D) parametrized modeling. The modeling approach is applied to several different road segment types, such as roundabouts, bicycle lanes, or railway underpasses. In practice, these different elements need to be modeled in various software applications. Collaboration between planners when designing these shared spaces in transportation infrastructure, e.g., using the IFC data model, still is challenging due to missing interoperability. BIM for modeling road pavement was investigated by (Tang et al. 2020). They integrated the pavement structural analysis of the asphalt surface layer into the design process using a framework developed in Dynamo. They stated that BIM enables the possibility to add more analysis indicators and to consider the whole pavement layer, which can support the design more efficiently. The use of BIM and IFC also was investigated for planning future traffic technologies such as intelligent transportation systems in order to provide a formal description of these systems for road networks and to use the resulting IFC models for traffic simulations (Mirboland and Smarsly 2021). For asset management, a semantic description is essential for these future BIM applications, and formalization and standardization of these road and bridge semantics are being discussed further.

Several existing approaches have been proposed for BIM-based asset management of transportation infrastructure. Because most infrastructure assets are existing objects, there is considerable potential for the integration of BIM into AM processes (Pocock et al. 2014; Chancey et al. 2017). Realistic representation of objects significantly can improve the quality of decisions regarding maintenance measures. In addition, BIM enables an improvement of the existing methods of data acquisition and storage, through seamless information exchange over the entire life cycle of the road infrastructure. Currently, approaches are in the form of BIM pilot projects (Jackson 2018), primarily considering planning and execution phases and mimicking a “digital construction site” (Parlikad and Catton 2018). A particular issue noted is a lack of uniform specifications for data exchange between partners. A general description of processes, data structures, and flows within national roads authority (NRAs) does not yet exist in a comprehensive and usable form for the application of the BIM method. This hampers the use of novel data streams via technologies such as unmanned aerial vehicles (UAVs), e.g., drones and photogrammetry (Hajdin et al. 2018).

The Semantic Web integrates different internet resources and adds a semantic layer describing the resource with additional metadata (Berners-Lee 2006). Therefore, ontologies are used to define a schema for the interpretation of metadata from these resources (Staab and Studer 2009). Ontologies determine the meaning of the metadata instances for a generic concept of machine-readable data access. Furthermore, the semantic layer can be utilized to link data and resources across the World Wide Web using Semantic Web technologies (Domingue 2011). This linkage is called linked data (Berners-Lee 2006). The Semantic Web technology stack consists of a layered set of technologies developed for use in Semantic Web environments and applications (Domingue 2011). Identifiers according to the uniform resource identifier (URI) syntax form the basis of each resource described. The exchange of data is performed using the Resource Description Framework (RDF) (Cyganiak et al. 2014) and the extended RDF schema (RDFS). Semantic Web data are structured using ontologies defined in the Web Ontology Language (OWL) (Motik et al. 2012). These data can be serialized into, e.g., RDF/Extensible Markup Language (XML) (Gandon and Schreiber 2014), Turtle (Beckett et al. 2014), or other syntaxes. To query data in the structured format, the SPARQL Protocol and RDF Query Language (SPARQL) was developed, which as a query layer can process all defined vocabularies and search the data record on the basis of triple pattern matching (Harris and Seaborne 2013). For validation of RDF-based data, the Shapes and Constraint Language (SHACL) has been developed and extended (Knublauch and Kontokostas 2017). Linked data and Semantic Web technologies increasingly are being researched and applied in the architecture, engineering, construction, owner, and operation (AECOO) sector (Pauwels et al. 2022). The development of ifcOWL as an exact representation of the IFC STEP formats in an OWL ontology can be seen as a starting point for accessing building data in a Semantic Web context (Beetz et al. 2009). Bonduel et al. (2018) implemented the conversion from IFC STEP to several construction ontologies as the IFC to Linked Building Data converter (IFC2LBD). Moreover, a central ontology for representing the topology of a building or a structure was proposed by Rasmussen et al. (2017) as the Building Topology Ontology (BOT). It represents the site, buildings, building stories, zones, building elements, and the spatial relationship between these entities. This ontology fulfills the minimal requirements to represent building data and to align with other ontologies that extend the elements with domain-specific information (Schneider 2019).

The number of published domain-specific ontologies for transportation infrastructure has increased in the last few years. There are several domain ontologies that consider the inspection and maintenance of bridges. Based on the BOT, a Bridge Topology Ontology (BROT) as a core ontology for representing a bridge was developed (Hamdan and Scherer 2020). It associates four additional ontologies as an extension for modeling the bridge type, bridge components, and building materials. With the Damage Topology Ontology (DOT) (Hamdan et al. 2019), the damage representation can be linked to bridge components defined in other ontologies, e.g., BROT or BOT. The DOT provides an ontological basis for bridge inspection and damage detection. The Bridge Maintenance Ontology (BrMontology) is defined with a focus on condition assessment and maintenance planning without alignment of existing ontologies (Ren et al. 2019). It consists of classes considering the structure, material, hazards, and other events. Another ontology focusing on Concrete Bridge Rehabilitation Project Management (CBRPMO) was developed to model domain information during the rehabilitation procedures (Wu et al. 2021). For the area of road AM, a variety of ontology developments mainly has focused on the operation and maintenance phase (Lei et al. 2021). For example, an important outcome of the European research project INTERLINK was the development of the European Road Object Type Library (EUROTL) (Luiten et al. 2018). This Object Type Library is available as the EUROTL ontology, which provides classes and properties for modeling infrastructure entities, actors, and operational activities and reuses concepts of the well-established Provenance Ontology Family (PROV) (W3C 2013). An ontological basis for the management of infrastructure information related to the requirements of European Road Directors has been provided. Within the scope of this research project, several test ontologies were developed which are oriented toward EUROTL and correspond to the respective national standards. One of these ontologies represents the German standard for bridge condition assessment, which is referred to in this work as the ASBING ontology.

Information management using BIM is specified in ISO 19650-1 (ISO 2018). To exchange information between project stakeholders, information containers can be used. According to DIN SPEC 91391-2 (DIN 2019), an information container can provide metadata along with arbitrary information content. Thus, these standards and specifications do not provide the container definition and syntax itself. Therefore, in recent years research has investigated how to exchange interrelated BIM data in containers. Some approaches are the Dutch standardized COINS container (Hoeber and Alsem 2016), the multimodel or BIM-LV-container (Fuchs and Scherer 2017), and the most recent Information Container for Linked Document Delivery (ICDD) (ISO 2020). Extensions of the defined openCDE interface according to DIN SPEC 91391-2 (DIN 2019) for specific container types, for example, using the ICDD (Höltgen et al. 2021), were analyzed, conceptualized, and implemented. The ICDD container utilizes Semantic Web technologies to provide metadata about the contained data, and the linking between these documents delivered within. The application of Semantic Web technologies enables an extendable structure of the container schema, unique identification of objects, and independent localization of data for integration of distributed data (Hoeber and Alsem 2016). The data schema of this information container relies on three main ontologies for the structure of the container, the included linksets, and further specialized human-interpretable link types based on the Semantic Web technologies RDF and OWL (ISO 2020). The standard also provides a data validation approach using SHACL. The information container can host several types of documents internally or externally, all of which are identified uniquely using URIs. Several approaches utilize the ICDD for validation (Hagedorn and König 2021) or for the integration into a common data environment (CDE) (Karlapudi et al. 2021).

The traffic authority is responsible for the AM to ensure safe and reliable infrastructure by employing the management group and the operational engineering group. The main technical tasks in infrastructure asset management focus on inspection and on planning and executing maintenance based on the condition of the infrastructure. The abstracted work process is performed by several stakeholders (Fig. 2). First, the manager plans tasks based on the available infrastructure data. Engineers provide the technical requirements and data needs of the planned task related to national standards. Then the commissioning can be prepared. After contractors receive the order, they can execute the work and deliver the requested or updated data back to the operating engineers. The engineers verify the quality of the work executed and data delivered against the requirements, and finally approve the work if the requirements are fulfilled. The data generated during the process are provided or exchanged in the form of information containers.

An information container can be used to bundle and link different types of data and documents (ISO 2018). The generic structure of the containers consists of an index.rdf file and three predefined folders—Ontology resources, Payload documents, and Payload triples—that are distributed in a ZIP archive (ISO 2020). The index.rdf file describes the container and its contents, including the respective metadata. The ontology resources folder is used to store employed ontologies. The mandatory container ontologies Container.rdf, Linkset.rdf, and ExtendedLinkset.rdf according to ISO 21597-1 (ISO 2020), and ExtendedDocument.rdf according to FAIRsharing.org (2021) must be included. These ontologies provide the class and property definitions to specify and link documents within the container. Depending on the scope of the container, utilized domain ontologies also are declared in this folder. The Payload documents folder is used to store all defined documents, e.g., 3D-object models, images, reports, and so forth. The Payload triples folder is used to store the links collected in the related linkset file and to store all RDF-based data sets, which are instances of domain ontologies.

In the work process depicted in Fig. 2, the data and the connection between data and process are shown as containers and dashed lines, respectively. The manager can access and query the available infrastructure data from existing relational databases connected to the 3D-object model for task planning inside the Asset information container. The planning data for a maintenance task can be collected directly in the Asset information container by the asset managers. The data exchange points and the related data scope are defined as a part of the task requirements. An information delivery manual based on ISO 29481-1 (ISO 2016) can be used. The level of detail of the data exchanged at each point must be defined. In this paper, business process model and notation (BPMN) is used to formalize the detailed process map for the use cases and to specify the content of the container for the exchange. The content of the container then is described in terms of the data scope, data type, and the connection between the data or documents. In addition to the IDM, the necessary data and documents, i.e., the infrastructure and technical specifications for executing the task, are provided in a Requirement container for the commissioning preparation. This Requirement container is created once throughout the workflow and is supplemented and handed over to stakeholders in each step. When the container is handed over to further workflows steps, the status and suitability of the container are changed accordingly. Thus, the whole workflow is documented within this container, and the history of changes and details of the previous content can be tracked. In addition, the contractor’s works also are recorded in this container as requested documents. The resulting Requirement container will be handed over via the ICDD platform to the contractor by receiving the order.

The contractor uses the Requirement container for retrieving the technical documentation of the infrastructure and as a template for capturing the requested data. Adding the requested information from the contracted task into the Requirement container, this container is transitioned into a Delivery container. This transition implies that the contractor modifies the Requirement container with all information included as a template container and adds each piece of the required information into the container during the work process. After successfully integrating the data, this container can be delivered to the operating engineers for approval. The same container is reused, and thus is only annotated with metadata (suitability and status) to embody the data flow in the overall workflow. After delivering the required documents and information into the container, it can be approved by the receiving operating engineers. Certain data can be selected and integrated into the existing relational database, which can be used for the review of the infrastructure information and as a basis for future maintenance tasks. This paper introduces two use cases to demonstrate the application of the Asset information container for planning maintenance tasks and to present the data exchange using Requirement container and Delivery container for a bridge inspection. The use cases were realized by providing an ICDD platform implementation.

To facilitate sharing, exchange, and visualization of data between different stakeholders in information containers, an information system called ICDD Infrastructure Asset Management Platform is implemented. To track the work process for a container concerning information management, the platform enables setting the container status according to the ISO 19650-1 (ISO 2018) status codes and workflows. The user access to the container can be determined depending on the relationship between the logged-in user role and the project. Functions for visualization, creation, manipulation, and deletion of the container content are provided. Data querying within the container and data integration from an existing relational database is implemented. A detailed description of the system architecture of the proposed platform is presented in the following section.

In this use case, the condition of bridge elements is assessed using the German guideline ASBING. The detected damage of an element is recorded with an image related to the respective IFC object. An IDM is defined for data exchange between different stakeholders in the inspection process. Fig. 4 shows a BPMN diagram. This formalization of processes within the scope of IDM particularly supports understanding complex workflows of BIM model exchanges between several stakeholders. The process typically contains detailed tasks for each stakeholder and the respective data exchange points. In this case, the process has just two data exchanges using the information container. The container content must be defined as an exchange requirements model for each data exchange. The operation engineer prepares the commissioning of the inspection with the necessary documents concerning the bridge structure. This information is collected in the ER1_requirement_container. The contractor uses this container as a template, and changes its name to ER2_delivery_container with status “Work in progress” and changes the suitability from “Suitable for requirement” to “Suitable for inspection.” These changes can be realized simply on the ICDD platform. Then, the inspection information as required can be added into the ER2_delivery_container. As a result, the ER2_delivery_container with the aggregated data is delivered. The operation engineer verifies the deliverables against the technical and exchange requirements. The verified information can be filtered by the engineer for specific tasks, e.g., maintenance planning.

The configuration of the requirement container and the delivery container related to the use case is displayed in Fig. 5. Regarding the type and the usage of the data, the documents are stored in the three container folders as defined in the ICDD standard. In addition to the ontologies required by ISO 21597 and the ICDD platform, the domain-specific ontologies also are considered in the folder Ontology resources for executing RDFS reasoning in the container to further process the data with SPARQL and SHACL. For the use case, the container employs three existing domain ontologies for capturing semantic data (Fig. 6).

In addition to the structure model BridgeModel.ifc for a BIM-enabled inspection, the operation engineer provides the predefined document templates [REQ]DamagePlacement.ifc and [REQ]DamageImage.jpg with the requested attribute as placeholders in ER1_requirement_container. Using the requested attribute, the information requirements can be defined digitally, fulfilling the process of information delivery and information approval both in practice and for the ideal process according to ISO 19650. The contractor can use the container template to deliver information and complete the ER2_delivery_container. The required documents for the damage description can be uploaded into the container. If more damages were captured, all related documents should be uploaded regarding the requirements of the defined template files in the Payload documents folder.

Semantic data are captured in Turtle files in the Payloads triples folder according to the defined domain ontologies. Links between IFC elements, images, and semantic data are specified in RDF files as so-called linksets. All linkset files included in the two containers are summarized in Fig. 7, providing the link description and the document containing the linked elements. The link description clarifies which data are associated with each other. These data form the connective elements that are contained as components or instances in the aforementioned documents. They then are linked using the link type Directed1toNLink that defines a direction via exactly one from-link element and a set of to-link elements defined by ISO 21597-2.

This use case demonstrates how decision-making can be supported with the help of cross-domain information containers. Steps 1–7 in Fig. 8 show the establishment of an information container with available data from an existing asset management database linked to road object models and the generation of an appropriate maintenance plan. Step 1 defines the scope of the generated information container. For example, an asset manager can use the information container to request the current condition of pavement road sections linked to the respective elements in a 3D model. Based on the result, they can plan the maintenance based on the geometry of the affected elements and the historical pavement data from the database considering time planning and cost estimation of the maintenance work to be executed.

A relational database RoadInformationDatabase (RIDatabase) is set up consisting of seven database tables based on the German NWSIB database for state-specific road maintenance. It contains four main information components: road section data, construction project data in connection with the road network information, inspection data in connection with the condition information, and the maintenance plan in connection with the planned pavement works. The pavement condition assessment with four key indicators (friction, evenness, rut depth, and crack width) available from the Condition table (Fig. 9) is the focused of Step 2. These condition data are recorded as instances of an appropriate domain ontology. In the same manner, the data of the maintenance plan must be acquired using a domain ontology regarding the database table the Maintenanceplan table of the RIDatabase. Considering both aspects, the EUROTL ontology is employed to capture the numerical values of the condition and the planned maintenance data as Step 3. In Step 4, the mapping rules for exporting data between relational databases and RDF-based payload triples are defined in the R2RML mapping language. The alignment between attributes of the Condition table and the classes and properties of the EUROTL ontology is defined as shown in Fig. 9.

To generate the container for this use case in Step 5, all contents are provided in Fig. 10. When the relational database is registered as the payload document RIDatabase using the extdoc:ExternalDatabaseLink class and the mapping rule is declared as RIDatabase.mappings.ttl and referred to the database link, the condition data can be integrated automatically into the container as payload triples RIDatabase.instances.ttl using the defined mapping. The connection of lane sections from the database to respective IFC elements is created and stored in the linkset file Ls_ifc_RIDatabase.rdf. To query and filter the relevant data to create the maintenance plan, the SPARQL query language can be used, and queries can be executed in the platform on the aggregated container data as Step 6. By reviewing the query result, the asset manager generates the maintenance program, for example, for the queried road sections in critical surface conditions, and incorporates the respective data into the information container in Step 7. These data are collected in the Maintenance.instances.ttl file. These instances of the planned program also are linked with the related IFC elements. The links then are recorded in the linkset file Ls_ifc_maintenance.rdf. As the last step, Step 8, the asset manager can import the relevant result back to the original database, an approach for which was introduced by Liu et al. (2022) and which will be implemented into the platform in the future.

For the BIM-enabled bridge visual inspection, the IFC model of a concrete road bridge is used that contains two bearing axes built with a foundation and abutment walls. The structure and traffic load are carried by a grid consisting of two main beams and three cross beams. The bridge substructure elements described previously are considered to demonstrate the visual bridge inspection use case. The topological representations of structure elements are described using BOT as shown in Fig. 12. The whole bridge structure was typed both as a bot:Building and a brot:Bridge to be able to use the generic topology hierarchy from BOT and to provide a more specific classification of the structure using BROT explicitly. Further classifications of BOT individuals can be inferred through the alignment between BOT and BROT as provided by Hamdan and Scherer (2020). The metadata of the inspection with the execution year and the assigned contractor are collected as instances of classes from the ontologies EUROTL and PROV. The links defined in the use case description are created between these instances and the elements of the IFC model.

The contractor collects the condition of the nine elements defined as BOT instances. Based on the German ASBING ontology, each element possesses three condition grades considering traffic safety, stability, and durability on a scale from 0 (no influence) to 4 (renewal is to be initiated). In this inspection use case, all elements of the substructure are assessed as having no influence on traffic safety and Grade 1 or 2 for stability and durability without the relevant need of maintenance, until the main beam at the south side has damage such as concrete cracking or spalling. It then receives a Grade 3 for both conditions and needs to be maintained shortly. The respective damage will be captured within the IFC model DamagePlacement.ifc for the localization and in an image DamageImage.jpg for visual assessment afterward. The IFC elements that are in a Stability grade 3 state can be selected as shown in the IFC viewer in Fig. 11 and linked to create a maintenance plan. Moreover, the model with the damage location is shown in the IFC viewer.

For planning the pavement maintenance based on the BIM model, a limited road section with a length of approximately 1,000 m was modeled. This road model contains only one direction and one lane without a terrain model. The underlying alignment of the road was built from an alignment element straight line. Because the current export of ifcAlignment in IFC 4x3 is not provided in the modeling application, the model was exported in IFC 4 without alignment elements. The road cross section consists of four layers: asphalt surface course, asphalt base course, base layer, and antifrost layer. In addition, a virtual layer over the pavement structure in the longitudinal direction was defined with element lengths of 100 m as a homogeneous section for the condition assessment.

The condition data for the 100 m homogeneous sections are recorded in the RIDatabase with the numerical values of friction, evenness, rut depth, and crack width. The database is connected to the information container as a payload document (Fig. 13). The mapping rules RIDatabase.mappings.ttl are defined using EUROTL to export the data from the database into the container. Fig. 14 shows an example of R2RML mapping rules for converting the data of column crackwidth from condition table of the RIdatabase into instances of the class eurotl:condition with the related pavement section as a spatial object. Fig. 15 shows the imported data set of one pavement section represented in triples as a result. The whole ontological data are captured as triples in the RIDatabase.instances.ttl, which then are linked with the homogeneous section of the IFC model.

Combined with the IFC model, the stakeholder can select the pavement sections with critical values of the condition indicators. Based on the query result, the pavement sections requiring maintenance can be determined. The recommended work, year, and cost are recorded in the maintenance plan linked to the sections. Fig. 16 demonstrates a query to filter the sections with a value of crack width of more than 3 mm through the SPARQL query. As a result, the two end sections between 800 and 1,000 m are returned and highlighted in the IFC model (Fig. 13). After a review of the IFC model, the maintenance plan can be made for the related sections with the required information using EUROTL.