Research Paper

Journal of the Computational Structural Engineering Institute of Korea. December 2020. 411-417,
https://doi.org/10.7734/COSEIK.2020.33.6.411

ABSTRACT


MAIN

  • 1. Introduction

  • 2. Extended IFC-BIM model for bridge inspection

  • 3. Integration of the bridge inspection information and extended IFC-BIM using ontology

  •   3.1 Ontology for bridge inspection information

  •   3.2 Integration process of extended IPF and bridge inspection ontology

  • 4. Testbed application for integration of extended bridge model and bridge inspection ontology

  • 5. Conclusions

1. Introduction

The cost analysis related to the insufficient interoperability in the capital facility industry of the U.S. was around $15.8 billion annual, and two-third of which was related to the operations and management phase cost (NIST, 2004). This shows the importance of interoperability in information management of the operation and maintenance phase. A high amount of inspection data and related information are generated in the life cycle of bridge facility management, such as sensing and monitoring data, damage data, GIS data, analysis data. Managing, integrating, sorting, and searching for all those data over a long period can be error-prone and time-consuming if interoperability is not maintained efficiently.

Industry Foundation Classes (IFC), the standard for Building Information Modeling/Model (BIM) is the key to the interoperability of BIM data models. However, the development of IFC has been mainly focused on buildings, so it can not fully support civil infrastructures such as bridges, tunnel, and railway. One of the challenges for BIM to manage the information of the bridge is that current officially reported IFC standard (IFC4) could not fully describe objects of bridge and their related semantic information and attributes (Lee et al., 2016).

In this paper, a conceptual framework for integration of the extended IFC bridge model and bridge inspection ontology was proposed. Firstly, the IFC entities for the bridge objects were proposed. Secondly, bridge inspection ontology was developed by following the practices and principles of ontology making. Bridge Inspection concepts were extracted by referring to the expert standard. Then afterward all the concepts were classified and their relations were determined by using the semantic triple method. Thirdly, the extended IFC information model for the bridge was integrated with the newly created bridge inspection ontology using the ifcOWL standard based IFC to RDF translator tool. Finally, a testbed case application was demonstrated. With the help of SPARQL query inspection data of guardrail crack was retrieved from the resulting final IFC based inspection ontology to validate the proposed framework.

2. Extended IFC-BIM model for bridge inspection

Industry Foundation Classes (IFC) is an international open data standard based on ISO 16739 to improve the interoperability of BIM applications (ISO-TC184/SC4, 2013). Recently, IFC is actively extended to describe civil infrastructures (buildingSMART International, 2020). However, it is still difficult to express the bridge data because of insufficient objects to represent the bridge components (Park et al., 2020).

The IFC schema is described using the EXPRESS language, which has an inheritance. The inheritance can express other structures that are not developed by inheriting the properties of the parent object. Fig. 1 shows the extended IFC entities for the bridge using the inheritance of IFC4 entities. In this paper, the IFC schema for the bridge model was extended by referring CRBIM (2015), Lee et al. (2017) and Park et al. (2020). The extended IFC entities for the physical information of the bridge are defined as IfcBridgeElement, which is added as a subtype of the IfcCivilElement. IfcBridgeElement includes IfcBridgeGirder, IfcBridgeMember, IfcBridgeSlab, IfcBridgeSlabSegment, IfcBridgeAbutment, IfcBridgeAbutmentSegment, IfcBridgePier and IfcBridgePierSegment. The IFC entity for the spatial information is defined as IfcBridgeStructureElement. The IfcBridgeStructureElement includes IfcBridge, IfcBridgeSpan, and IfcBridgeSpacePart. Among these entities, the IfcBridge represents the entire structure of the bridge, while IfcBridgeSpan and IfcBridgeSpacePart represent the space-related information of the bridge.

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F1.jpg
Fig. 1

Extended IFC entities for bridge structure

The extended IFC model data for the bridge was created through the procedure suggested by Kwon et al. (2020). Fig. 2 shows the process of bridge modeling in conventional BIM software (such as Revit) and then converting the modeling data into the extended IFC-BIM model data. The information of element, property, and geometry of the bridge object was extracted through Revit Application Programming Interface (API), and a new element by the extended entity was created again for each object. The newly created IFC Physical File (IPF) considers not only the element but also the relationship between them. The IPF can connect bridge inspection data because it can identify the objects. The IPF was transformed into an ontology model for the integration with the bridge inspection data.

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F2.jpg
Fig. 2

Process for bridge modeling based on extended IFC

3. Integration of the bridge inspection information and extended IFC-BIM using ontology

3.1 Ontology for bridge inspection information

In informatics and computer science, the essence of ontology is to model the structure of relations among entities in a formal and machine-readable manner. Gruber (1993) defined ontology as “an explicit specification of a conceptualization”. The purpose of creating the formal structure of conceptualization is to share information, to make knowledge reusable, to define domain information explicitly, and to analyze the conceptual knowledge structure (Noy and McGuinness, 2001). In other words, creating an ontology for any specific domain, such as bridge inspection, enables the aforementioned opportunities of information and knowledge management.

The key step of making ontology is to define the domain of interest and to determine it’s purpose (Noy and McGuinness, 2001). In this paper, bridge inspection is the target domain. AASHTO (2013) bridge inspection element taxonomy was adopted for creating the bridge inspection ontology (see Fig. 3).

AASHTO bridge inspection taxonomy provides the following five important features:

∙ Bridge structure related elements as well as bridge management elements

∙ Four types of grading condition

∙ Common defects based on the material type and structure type of elements

∙ Material classification

∙ Five types of feasible actions

Each of these features as concepts was mapped into the class of bridge inspection ontology (see Fig. 3). Other related information was inserted as the subclass of each one of these classes. Properties of the classes were defined by constructing the semantic triples from the bridge inspection concepts and relationships among them. The semantic triple method is a structure that consists from “Subject” and “Object” which are linked with “Predicate” (see Table 1) (W3C, 2014).

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F3.jpg
Fig. 3

Main classes of bridge inspection ontology

Table 1.

Semantic triple classification for bridge inspection domain concepts

Subject (Classes) Predicate (Properties) Object (Classes)
Deck equivalentTo Slab
Slab equivalentTo Deck
Element equivalentTo Component
Component equivalentTo Element
Deck transfersLoadTo Bridge
Slab transfersLoadTo Bridge
CommonDefect mayOccurIn Element
CommonDefect has DefectName
CommonDefect has DefectIDNumber
Element has ConditionState
: : :

3.2 Integration process of extended IPF and bridge inspection ontology

ifcOWL provides a web ontology language expression of the IFC schema. As mentioned in chapter 2, the IFC standard expresses the BIM model, and model data can be conveniently connected to material, GIS, sensor, and other data types with ifcOWL. Pauwels and Terkaj (2016) suggested a procedure to translate the IFC EXPRESS schema into ifcOWL ontologies.

In this research, a conceptual framework was proposed for the extended IFC and bridge inspection ontology integration procedure (see Fig. 4). In the Fig. 4, there are three stages in the testbed application of the proposed framework. Stage one is to create and prepare the IFC physical file of the extended IFC test bridge model. Stage two main goal is to integrate ifcOWL version of the extended IFC bridge model into bridge inspection ontology. ifcOWL version of the extended IFC bridge model is obtained by utilizing the ifcOWL based IFC to RDF translator. While the bridge inspection ontology was created by the method, which was mentioned in chapter 3.1. In the stage three, test inspection data sets were asserted into the resulting extended IFC bridge inspection model ontology. Test inspection data sets consist of concrete guardrail surface damage such as crack and efflorescence information.

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F4.jpg
Fig. 4

Framework for the extended IFC model integration with bridge inspection ontology for information management

4. Testbed application for integration of extended bridge model and bridge inspection ontology

The test bridge information model was created in Autodesk Revit (Autodesk, 2020). The test model is a three-span PSC girder bridge with four piers. In each span of the test bridge model, there are two concrete guardrails, four girders, one slab. In total, the test model bridge has the following elements: three slabs, six guardrails, twelve girders, and four piers. Each element has a classification system and identification ID assigned by using the ‘Property Tool’ of Revit. Fig. 5 shows an example of the generated test model and properties. The S1 bridge guardrail has PBS code ‘AB102’ and Object_ID ‘AB102_S1’. Classification system code and identification ID are better managed in the IFC-BIM model and also can be used as linking points to other information sources. Furthermore, identification ID’s can make it easier to identify the entities that are translated into a format other than IFC. For that reason, they are assigned to the BIM model.

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F5.jpg
Fig. 5

Example of the test model and properties

The methodology mentioned in Chapter 2, has transformed the information model in Revit to an extended IFC based information model. Fig. 6 shows the hierarchical information of the model. Fig. 6(a) is the hierarchical structure in the Revit API, and Fig. 6(b) is the hierarchical structure in the Solibri model checker. The following are the transformation details of the spatial elements. ‘Bridge_1’ is a spatial element representing the test bridge, while ‘Superstructure’ and ‘Substructure’ are spatial elements representing superstructure and substructure. ‘Bridge_1’ was converted to IfcBridge. ‘Superstructure’ and ‘Substructure’ were converted to IfcBridgeSpacePart. To confirm the extended IFC-entities are correctly recognized in the model, the test model entities were converted to IFC4 entities and were checked in the Solibri model checker. Afterward, with the help of ifcOWL based IFC to RDF converter tool, the ontology version of the extended IFC-BIM bridge model was obtained. In Fig. 7, the conversion of the ontology individuals into the extended IFC entities by referring to the extended IFC bridge model is also shown. Fig. 7(a) is the extraction of the entities related to IfcBridgeMember (#10019), which is one of the concrete guardrails. The relations between the extracted entities are as follows. ‘IfcBridge’ (#10071) is connected to IfcRelAggregates (#10089). IfcBridgeSpacePart (#8608) is connected to IfcBridgeMember (#10019) through IfcRelContainSpatialStructure (#10294), which connects spatial entities and physical entities. IfcBridgeMember (#10019) is connected with IfcPropertySet (#10296) through IfcRelDefinesbyProperties (#10186), which connects entities and properties. Fig. 7(b) shows the resulting extended IFC entities as ontology individuals.

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F6.jpg
Fig. 6

The hierarchical structure in BIM applications

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F7.jpg
Fig. 7

Conversion of the ontology individuals into the extended IFC entities by referring to the extended IFC bridge model

Protege is an ontology editor platform for utilizing and editing the OWL ontology (Musen, 2015). Once the ifcOWL version of the extended IFC-BIM bridge model was ready, by using the Protege platform, the existing newly created bridge inspection ontology was merged with the ifcOWL ontology. After merging two ontologies, test crack data located in the guardrail elements was asserted into the resulting ontology. The guardrail can be mapped in the extended IFC-BIM bridge model semantic information as IfcBridgeMember as mentioned previously.

For the validation and analysis purposes, six inspection event sets were asserted into the resulting ontology. Each inspection event set has a unique set of data, consisting of bridge name, inspection location, defect type, defect amount, taken repair action, and inspection image document ID. In Fig. 8 as demonstration, how the inspection event 1 and all of the related data sets were asserted have been shown. The advantage of managing OWL ontology in the Protege is that it allows asserting three different types of properties as a relation between classes and individuals. And those three types of properties are object property, data property, and annotation property. The data property is used for asserting relation to any data information. Object property is used for asserting the relation between classes and individuals. And annotation property is asserted to add more detailed semantic explanation about the concept. When it comes to utilizing the reasoning ability features provided in the Protege, annotation properties are not accounted during reasoning, while the other two types of properties are used for inferred assertions.

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F8.jpg
Fig. 8

Demonstration of “Inspection event 1” assertion

Finally, after asserting the test data sets, the SPARQL query was utilized to retrieve inspection information from the extended IFC-BIM based bridge model and bridge inspection ontology integration framework, which can be seen in Fig. 9. As a scenario, the facility engineer would seek information about all the damage related data in the concrete guardrails. The query result shows the crack information such as crack length based on the crack width type. The process can be repeated for the different types of inspection data retrieval such as crack width size and crack depth. Because these inspection data can be similarly linked into the proposed framework.

/media/sites/jcoseik/2020-033-06/N0040330608/images/Figure_jcoseik_33_06_08_F9.jpg
Fig. 9

SPARQL query result for the validation of the developed ontology based framework

5. Conclusions

In this research, the framework for the extended IFC-BIM and bridge inspection ontology integration was proposed to address the interoperability need in BIM and bridge inspection field.

Firstly, the IFC extension of bridge entities was proposed because the current version of the IFC standard does not support bridge entities. Secondly, bridge inspection ontology based on the AASHTO standard was developed by utilizing the semantic triple approach. Finally, ifcOWL based IFC-BIM bridge model and bridge inspection ontology integration has been demonstrated.

A testbed application was carried out on the crack inspection data for the validation of the proposed method. SPARQL query was utilized for retrieving inspection data from the integrated extended IFC based bridge inspection ontology. In the result, crack data connected into the IFC-BIM entities was successfully retrieved. This methodology can be used for the inspection information management of other civil infrastructures such as road, tunnel, railway and etc. The integration model has interoperability of BIM applications and inference ability of inspection data using information relationships. It is expected to minimize the information loss during facility operation and improve inspection data analysis.

Future work should consider a suitable database for inspection data, for example, RDF based graph database. Inspection data information are semantically rich and relation dependent. Therefore, the graph database can be effective in managing the inspection data. Other future works can be related to computational analysis. Because integration between BIM model and inspection ontology could provide an opportunity to extract information for computational analysis.

Acknowledgements

This work is supported by the Korea Agency for Infrastructure Technology Advancement (KAIA) grant funded by the Ministry of Land, Infrastructure and Transport (Grant 20RBIM- B158185-01).

References

1
AASHTO (2013) AASHTO Manual for Bridge Element Inspection, American Association of State Highway and Transportation Officials, Washington, D.C.
2
Autodesk (2020) Autodesk Revit 2020. https://help.autodesk.com/ view/RVT/2020/EN (accessed Sep., 28, 2020).
3
buildingSMART International (bSI) (2020) bSI UML Model Report: Harmonised UML Report - Part 1, IR-CS-WP2, buildingSMART International, p.70.
4
China Railway BIM Alliance (CRBIM) (2015) Railway bIM data standard version 1.0, China Railway BIM Alliance, p.218.
5
Gruber, T. (1993) What is an ontology? http://www-ksl.stanford. edu/kst/what-is-an-ontology.html (accessed Sep., 28, 2020).
6
ISO-TC184/SC4 (2013) ISO 16739:2013 Industry Foundation Classes (IFC) for Data Sharing in the Construction and Facility Management Industries.
7
Kwon, T.H., Park, S.I., Jang, Y.H., Lee, S.-H. (2020) Design of Railway Track Model with Three-Dimensional Alignment based on Extended Industry Foundation Classes, Appl. Sci., 10(10), p.3649. 10.3390/app10103649
8
Lee, S.-H., Park, S.I., Kwon, T.H., Seo, K.-W. (2017) Civil Infrastructure Information Modeling Method based on Extended IFC Entities using BIM Authoring Software, J. Comput. Struct. Eng. Inst. Korea, 30(1), pp.77~86. 10.7734/COSEIK.2017.30.1.77
9
Lee, S.-H., Park, S.I., Park, J. (2016) Development of an IFC- based Data Schema for the Design Information Representation of the NATM Tunnel, KSCE J. Civil Eng., 20(6), pp.2112~2123. 10.1007/s12205-015-0123-8
10
Musen, M.A. (2015) The Protege Project: A Look Back and a Look Forward, AI Matters, 1(4), pp.4~12. 10.1145/2757001.275700327239556PMC4883684
11
NIST (2004) Cost Analysis of Inadequate Interoperability in the US Capital Facilities Industry, (NIST) GCR 04-867, National Institute of Standards and Technology, MD. USA, p.210.
12
Noy, N.F., McGuinness, D.L. (2001) Ontology Development 101: A Guide to Creating Your First Ontology, KSL-01-05, Knowledge Systems, AI Laboratory of Stanford University, CA, USA, p.25.
13
Park, S.I., Lee, S.-H., Almasi, A., Song, J.H. (2020) Extended IFC-based Strong Form Meshfree Collocation Analysis of a Bridge Structure, Automation in Construction, 119, 103364. 10.1016/j.autcon.2020.103364
14
Pauwels, P., Terkaj, W. (2016) EXPRESS to OWL for Construction Industry: Towards a Recommendable and Usable ifcOWL Ontology, Automation in Construction, 63, pp.100~133. 10.1016/j.autcon.2015.12.003
15
The World Wide Web Consortium (W3C) (2014) RDF 1.1 Primer, https://www.w3.org/TR/rdf11-primer/ (accessed Sep., 28, 2020).
페이지 상단으로 이동하기