Proceedings of the Institution of Civil Engineers -

Bridge Engineering

ISSN 1478-4637 | E-ISSN 1751-7664
Volume 170 Issue 3, September, 2017, pp. 204-218
Themed issue on information technology in bridge engineering and construction
Open access content Subscribed content Free content Trial content

Full Text

In addition to the traditional benefits associated with the installation of structural health monitoring systems, reductions in construction, operational and maintenance costs, and improved performance and quality can be achieved by effectively using the acquired data. However, considered in isolation, the raw data are of little use and value. They must be processed and put into a geometric context within the infrastructure asset, which facilitates the interpretation and analysis of the data. This supports informed decision making, which in turn leads to effective actions. This study outlines a new approach that enables the modelling of structural performance monitoring systems in a Building Information Modelling (BIM) environment and hence permits sensor data to be visualised directly on BIM models. The paper addresses aspects related to: (a) interoperability and standard data models; (b) management and visualisation of monitoring data; and (c) data interpretation and analysis. A prestressed concrete bridge, with a comprehensive built-in structural performance monitoring system, has been used as a case study. The case study demonstrates that by including and visualising monitoring data directly on BIM models the acquired data gain geometrical context within the built asset, which facilitates better interpretation, analysis and all the data-sharing benefits associated with the BIM approach.

Monitoring structural performance is becoming common practice for a wide range of infrastructure assets both in terms of type and size. Critical infrastructure assets justify the additional investment in structural performance monitoring systems because unexpected failures and breakdowns would represent significant losses. Nowadays, owing to advancements in sensing technologies that reduce fabrication and installation costs while increasing reliability, these types of investments are becoming easier to substantiate and methods have been developed to identify their potential value (Vardanega et al., 2016). Moreover, data acquired by these systems can be used to devise strategies to reduce operational and maintenance costs, improve performance and quality, validate structural solutions, and develop more efficient designs and construction processes for future projects. For example, monitoring systems have been used to support the numerical modelling of existing bridges to aid in assessing current conditions (Banerji et al., 2014).

Structural monitoring systems usually output raw data that is of little use if considered in isolation, which can be considered as one of the identified issues for structural monitoring (Aktan et al., 2000). These raw data need to be processed and organised so that they can be easily accessed, exchanged and visualised. This increases the value of the acquired data by facilitating better interpretation, analysis and decision making. The management and exchange of monitoring data is addressed by the information technology approach known as building information modelling (BIM). Its main purpose is to manage digital representations of all information related to a built asset during its entire life cycle, to improve productivity and quality while reducing costs. The BIM approach has been employed mostly for the design and construction phases of built assets’ life cycles. As-designed BIM models, digital representations of the built asset to be constructed, are developed and used as the basis to implement the BIM approach. They facilitate collaboration between the parties involved; increase the quality and performance of the end products; reduce conflicts; increase predictability of the design and construction processes; reduce material waste; and contribute to faster construction delivery.

The operational phase of a built asset life cycle could represent the largest opportunity for cost reduction because it represents the largest share of the entire life-cycle cost. Despite this, BIM provisions, for example, software solutions, standards, business cases, pilot projects and so on, are not yet sufficient. For instance, BIM models that represent the actual conditions of the constructed asset are not commonly used. These as-built BIM models are essential to adopt the BIM approach fully during the operational phase. The as-built BIM models should include data related to anomalies, damage and performance, which is even less common because in practice much of the data resides in accompanying documents (Dossick and Neff, 2010). Moreover, lack of interoperability between software solutions and difficulties in exchanging information limit the benefits of adopting the BIM approach (Ferrari et al., 2010), and the existing standard data models are not sufficient to describe fully infrastructure assets and structural monitoring systems (Davila Delgado et al., 2015; Gerrish et al., 2015; Smarsly and Tauscher, 2015).

An overview of a new approach to model structural performance monitoring systems is presented in this paper. The approach employs a standard data model to include and visualise structural performance monitoring data directly on BIM models. This approach will then facilitate the development and use of semantically rich as-built BIM models to manage sensor data in a BIM environment. Aspects regarding: (a) interoperability and standard data models; (b) management and visualisation of monitoring data; and (c) data interpretation and analysis are particularly addressed in this paper. A fibre-optic-based structural monitoring system installed in a prestressed concrete girder bridge in Staffordshire, UK is used as a case study. A large data set is presented in this paper that captures the development of strains within the reinforced concrete deck and prestressed concrete girders during the continuous monitoring of the concrete deck curing of the bridge.

A robust exchange of information, that is, without any errors or data loss, is central to the successful adoption of the BIM approach. This is a big challenge given the fragmented and varied nature of the construction industry, in which all-encompassing software solutions are non-existent and different parties use different software (Pauwels, 2014). As such, open standard data models have been developed to provide interoperability between parties. These open, or non-proprietary, data models are publicly available and prescribe rules to format and exchange data, which facilitate interoperability because any software solution can use them. To be able to employ the BIM approach for tasks related to structural performance monitoring, open standard data models that fully describe the infrastructure assets, monitoring systems and processes, and that manage and visualise the acquired data are required. In relation to monitoring and sensor data, many standard data models have been developed, as reported by Hu et al. (2007) and Lee (2007). In this paper, only standard data models developed by Building Smart and the Open Geospatial Consortium (OGC) are addressed as they are the only ones closely related to the construction industry.

The OGC develops standard data models that are focused on navigation, facility planning, and emergency and asset management. These include, for example: CityGML for three-dimensional (3D) modelling of cities; IndoorGML for indoor navigation; WaterML for describing data from water observations; and InfraGML for infrastructure assets (currently under development). Regarding monitoring, the OGC supports the sensor web enablement (SWE) initiative that provides web services and communication protocols for accessing online repositories of sensor data. SensorML (Botts and Robin, 2014) has been developed as part of the initiative. It describes devices and processes related to complex monitoring systems (Robin and Botts, 2006). However, its main limitation is that the object being monitored cannot be modelled and hence the geometric context, which is required for data interpretation, cannot be available.

Building Smart develops and maintains the industry foundation classes (IFCs) (Liebich et al., 2013), which constitutes a specification that seeks to provide descriptions to model all data related to all phases of the life cycle of a built asset. It is mostly used to describe data related to buildings during the design and construction phases. Building Smart is continually increasing the IFC capabilities. Currently, extensions to the specifications are under development to enable the description of infrastructure assets, for example, IFC bridge and IFC road. However, their application is very limited because they are not official parts of the specification and are not supported by authoring tools. With regards to monitoring and sensor data, the IFC specification is able to describe basic monitoring systems, as it includes entities intended to model building automation and control systems such as HVac (heating ventilation and air conditioning), plumbing, electrical and so on. It does not have the same flexibility and capabilities to model complex monitoring systems as SensorML, but it is able to model the object being monitored in a standard widely used in the construction industry.

Despite the wide range of open standard data models available, the existing models are not sufficient to fully describe monitoring systems and processes or to effectively manage and visualise sensor data (Davila Delgado et al., 2015). Asset performance cannot be correctly managed in a BIM environment. The size of datasets, accuracy and levels of detail, and interoperability with existing formats to store historical performance data are challenges for IFC implementation (Gerrish et al., 2015). Additionally, it is difficult to include data related to the configuration and topology of the sensor network, interaction protocols, monitoring strategies, embedded algorithms in sensors and so on. A compilation of alternative approaches used in practice to deal with the lack of capabilities has been presented in the literature (Davila Delgado et al., 2015).

Regarding structural performance monitoring, two cases exemplify efforts to integrate monitoring data into an open BIM software environment. In the first case, strain sensors in a building were modelled in a BIM authoring tool (Rio et al., 2013). The strain sensors were modelled as user-defined instances of smoke sensors because the IFC specification does not considers any type of structural sensors. Although the approach for modelling the sensors and exporting the BIM models between authoring tools was described, the paper does not report how the data have been used. In the second case, data collected by temperature sensors in concrete elements were included in BIM models and also visualised using charts (Chen et al., 2014). In this case, the reported solution succeeds in integrating the monitoring data into a BIM software environment, but the data are still presented in a traditional manner and do not take advantage of the BIM model itself. Note that other proprietary solutions exist, but have not been considered here because of their ad-hoc nature, which presents interoperability difficulties. These are mostly web-based solutions, in which the monitoring data can be accessed using a two-dimensional (2D) graphic interface. The data are presented in charts and spreadsheets, and the visualisation is limited to the location of sensors within the built asset in 2D diagrams.

For the approach presented in this paper, the IFC specification has been used as a basis to model the monitoring system and to include and visualise sensor data directly on the BIM models. The lack of existing capabilities has been overcome using proxy entities and user-defined property sets.

This section presents a new approach to model structural performance monitoring systems and to include and visualise sensor data directly on BIM models. The objectives of the structural monitoring systems dictate the requirements for data modelling and visualisation. Therefore, it is important to define clear objectives for the monitoring systems and to consider the future interpretation of the acquired data. As noted by Webb et al. (2014), the objectives of most structural monitoring systems can be categorised as follows: (a) anomaly detection, to detect fluctuations on measured parameters; (b) sensor deployment studies, to test different sensor technologies; (c) model validation, to validate whether the initial assumptions and the predicted responses correctly represent the actual physical situation; (d) threshold check, to detect when monitored parameters surpass a predetermined threshold, which could indicate problems; and lastly (e) damage detection, to determine type, location, extent and rate of damage in the structure. These objectives are prescribed by the stakeholders, for example, asset owners, asset managers and operators, structural engineers, contractors, researchers, authorities, users and so on, depending on the condition of the asset in consideration or the phase of the project if the asset is yet to be built.

3.1 Modelling structural monitoring systems

Defining the purposes of the modelled system is the first step to model a structural monitoring system. Note that ‘modelled system’ refers to the abstract description of the actual structural monitoring system installed on the infrastructure asset. Commonly, the purposes seek to facilitate: (a) development of definitive designs of structural monitoring systems; (b) deployment, maintenance and operation; (c) visualisation of monitoring data; and (d) simulation of monitoring processes. The objectives of the structural monitoring systems should also be considered when defining the purposes and requirements of the modelled system, for example, structural monitoring systems for threshold checks and model validation would have specific visualisation requirements when compared to other purposes.

A preliminary design of the structural monitoring system should be in place before starting the development of the modelled system. The following actions are usually taken to develop a preliminary design of a structural monitoring system. Step 1, define the structural behaviours to be monitored, for example, to monitor strains in the beams of a bridge caused by traffic loads. Step 2, define the monitoring approach and the structural elements to be monitored. The required devices to monitor the defined behaviours are selected in this step. Usually, three types of devices are needed in a monitoring system, namely, sensors, a communication network and a processing unit. Step 3, define the physical installation process of the monitoring system. Requirements for the modelled system should then be defined, which relate to: (a) level of detail, for example, a modelled system for scheduling maintenance would require a higher level of detail than one for anomaly visualisation; (b) level of accuracy; (c) types and frequency of recorded data; (d) the users of the modelled system, for example, an asset manager would require different data displayed in a different manner than a structural engineer; and (e) retrieval of data, that is, data stored directly on BIM models or linked from databases.

The system is modelled so that it closely represents the real-life situation using an object-oriented approach. Data are represented in units called entities that have attributes. These entities can represent physical objects (e.g. a sensor, a structural element and so on) or abstract concepts (e.g. a process or an event). Various modelled entities are aggregated into ‘sensor systems’, which in turn are aggregated into ‘monitoring assemblies’. The structural behaviour to be monitored and the structural elements, in which the sensor systems and monitoring assemblies are installed, define how the aggregation is carried out. The aggregated and individual entities are linked with entities representing structural elements. Figure 1 shows a diagram of a modelled system, in which rectangles represent modelled entities and attribute sets, dashed rectangles represent aggregations, and lines denote simple associations. Indentations represent hierarchical levels. For each type of entity, various attribute sets should be defined depending on the data and attributes that need to be assigned to the modelled entity, for example, geometrical properties, location, materials, monitoring strategies, sampling rates, data normalisation, raw data, derived data, types of visualisation and so on. Examples of such types of attribute sets are presented in Figure 2. Once the general framework of the modelled system has been devised, then it can be instantiated in the next step. The modelled entities can then be populated with the acquired and inferred data. The system has been modelled using Autodesk Revit. Proxy elements and user-defined attribute sets have been used because the IFC specification does not include all of the necessary entities to model the system. This enables management of structural performance monitoring data in a BIM environment and provides basic interoperability.

figure parent remove

Figure 1. Diagram of the modelled system showing selected monitoring entities and attribute sets

figure parent remove

Figure 2. Examples of monitoring attribute sets for monitoring assemblies, sensor systems and sensor entities

3.2 Processing and management of sensor data

Data as outputted by the structural monitoring systems cannot be used directly. Before the data can be interpreted, used for analysis, and included in BIM models, they first need to be processed into the correct physical quantity and units. They also need to be corrected for other phenomena that may affect the measurements, such as ambient temperature. This data processing is usually not carried out with the authoring tool, but with other software solutions. The processed data are then stored in plain text files or spreadsheets and subsequently imported into the authoring tool. This process can be automated by developing additional software tools that use the authoring tool application programming interface (API). Additionally, processing units provide only the recorded measurements, and do not include data relating to the location of the sensors or their spatial and hierarchical context within the object being monitored. These data must be inferred from the design of the structural monitoring system, the modelled system and additional documentation. Based on these inferred spatial and hierarchical data, every entity is instantiated at its respective location and populated with its respective acquired data. The attributes of the instantiated entities are also populated. Note that, currently, BIM models are mostly static representations of built assets at a particular point in time and BIM provisions only provide basic capabilities to represent dynamic data. In this sense, to be able to fully represent dynamic data, the BIM models should be able to automatically update values and attributes given changes in an external data source. In the presented case study that follows, only data belonging to certain time frames have been included in the BIM models.

3.3 Data visualisation

Facilitating interpretation, analysis and decision making are the main aims for visualising data acquired by structural monitoring systems. An effective visualisation of the acquired data will ultimately increase the value of those data. However, visualising structural monitoring data entails different requirements than traditional visualisation of BIM models. Different types of visualisations must be developed for the different objectives of the interested stakeholders. For example, an asset manager interested in identifying anomalies would require a different visualisation than a structural engineer seeking to evaluate the in-service performance of specific structural elements. Three categories of data can be visualised: (a) data acquired by monitoring systems, which usually are presented only in spreadsheets and graphs; however, by presenting the acquired data directly on BIM models, they gain geometrical and spatial context within the built asset, facilitating their interpretation; (b) derived information from the acquired data can be visualised as well – as an example, for a monitoring system that has been installed for the purposes of threshold checking, only the locations where the defined boundaries have been exceeded need to be visualised, as opposed to the underlying data set; (c) the configuration and topology of the sensor network and the components and their functioning states can also be visualised to facilitate operational and maintenance tasks. Alternative visualisation is not a common concept for BIM environments. In this case, specific BIM models have been developed for each alternative visualisation. They require alternative geometrical and material attributes. More importantly, the alternative visualisation attributes are linked, and given defined scales and filters to varying monitored parameters, so that changes in the monitoring data can be visualised.

A fibre-optic strain sensor based structural monitoring system has been installed in a newly constructed prestressed concrete railway bridge in Staffordshire, UK. This new bridge is one of 11 new structures comprising a major new rail redevelopment on the West Coast main line known as the ‘Stafford Area Improvements Programme’. Further details on the project are reported by Gibbons et al. (2015). The bridge carries a single lane of electrified railway using longitudinal precast prestressed concrete beams (types TY7 and TYE7) as main load-bearing elements and a reinforced concrete deck that is cast in situ. The 11·2 m single-span structure is simply supported on piled reinforced concrete abutments and concrete wing walls. The installed structural monitoring system has been designed to monitor various structural elements during the manufacturing, construction and operation phases of the project. The particular focus of this paper includes the analysis and visualisation of a large monitoring data set that captures the evolution of strains in the prestressed TY7 concrete beams, transverse bars and the concrete deck during the curing of the concrete deck. In particular, the aim of this study is to investigate the effect of concrete shrinkage and thermal strain transfer from the cast-in-situ deck and infill to the prestressed concrete girders. With this particular structural system, the large volume of fresh concrete (i.e. of the infill and deck) is expected to experience large shrinkage strains relative to the older prestressed concrete beams. A certain portion of these additional strains will then be transferred to the beams by way of concrete–concrete and concrete–steel bond. Shrinkage of the concrete in situ will induce a sagging moment in the beams (Hendy and Smith, 2007). Studies have demonstrated that this differential shrinkage between the concrete deck and girder is a primary cause of deck cracking (French et al., 1999). It is worth noting here that any other data set could have been chosen; the specific data presented in this paper are chosen to demonstrate the great benefits that could be achieved when the sensor data are modelled in the BIM environment.

4.1 The structural monitoring system

The specific monitoring objectives for this phase of the project were to quantify the variations in strain in various structural elements due to the casting and curing of the concrete deck, and to provide baseline measurements for future monitoring. The purpose of the modelled system is to provide an intuitive 3D visualisation of the monitoring data for preliminary assessment of structural behaviour.

Two fibre-optic-based monitoring systems were employed in this bridge, a distributed fibre-optic system (DFOS) and a point fibre-optic system (PFOS). The DFOS was based on the use of Brillouin optical time domain reflectometry (BOTDR) and the PFOS was based on the use of fibre Bragg gratings (FBGs). Both the DFOS and PFOS were included in the modelled system. However, for simplicity, only the results from the PFOS are presented in this paper.

The FBGs measure dynamic strain changes at discrete locations. A variety of methods are available for manufacturing FBGs, however, each method operates on the same principle of altering the refractive index at a particular location along the length of the fibre in order to create a dielectric mirror of a specified wavelength, known as the Bragg wavelength. For the FBG strain sensors used in this study, this was achieved by exposing the optical fibre core to a periodic pattern of ultraviolet light. When light passing through the optical fibre meets a grating, a particular light spectrum is reflected from that grating. When an FBG is strained, the shift change in Bragg wavelength is measured and correlated to a particular strain value. Each individual grating can be manufactured to correspond to a particular wavelength, thereby allowing multiple gratings to be produced along a single fibre. The FBGs used in this study consisted of low-bend-loss fibre and they were manufactured at a 1 m spacing along the length of the fibre. To provide added durability during installation and operation, an additional glass-fibre-reinforced polymer (GFRP) coating was applied. An FBG analyser produced by Micron Optics (sm130–700) was used in combination with a Micron Optics channel multiplexer (sm041), which allows the system to interrogate 16 channels up to 250 Hz (or four channels up to 1000 Hz). To compensate for temperature variations that affect the refractive index of glass and thermal strain in concrete, separate FBG temperature compensating sensors were installed in parallel with the strain sensor cables. Given that the strain sensor cables measure the total strain due to both mechanical strain and temperature changes, the measured temperature strain values must be subtracted from the total strain change values to isolate changes due to mechanical strain alone. The calculations and formulae used to carry out these temperature compensations are reported below.

In total, 140 FBG sensors were installed on the main structural elements of the bridge, including six of the nine prestressed concrete girders and at two transverse locations within the reinforced concrete deck and transverse cross ties. The detailed layout of the sensor network and installation procedures is presented in Figures 3 and 4. Figure 5 presents the sensor systems that were active during the curing of the concrete deck.

figure parent remove

Figure 3. Prestressed concrete girder layout and concrete deck plan: n, units are in mm. FOC (Fibre Optic Cables), PCC (Prestressed Concrete Beams).

figure parent remove

Figure 4. (a) Typical prestressed concrete girder sensor layout (section A). (b) Typical transverse cross-section and sensor layout (section B), units are in mm. FOC (Fibre Optic Cables), PCC (Prestressed Concrete Beams).

figure parent remove

Figure 5. Sensor systems that were active during the curing of the deck

Sensor installation proceeded over the course of several months as the structure was being constructed (see Figure 6). The prestressed beams were fabricated and instrumented offsite and were then transported and installed on the main bridge abutments. The seven internal TY7 beams and two edge TYE7 beams were tied together using transverse reinforcing bars that run through cast-in voids within the beams at 610 mm spacing. Once the ties were installed, fibre-optic cables were installed on the ties at both the mid-span and quarter-span of the bridge. Once the top and bottom deck reinforcing mats were set and tied in place, additional sensors were installed transversely on the top mat at the same mid-span and quarter-span locations as the instrumented transverse ties. All sensors were secured to the reinforcement using plastic cable ties spaced at regular intervals. Additional fibre-optic routing cables were spliced to the main sensor cables and routed to a central housing unit adjacent to the bridge to facilitate monitoring operations.

figure parent remove

Figure 6. Bridge under construction during deck casting

4.2 Data pre-processing
Strain and temperature changes along an optical fibre are linearly proportional to changes in the wavelength of the reflected light measured by the fibre-optic sensors. The raw data that are collected and processed by the fibre-optic analyser consist of a timestamp and wavelength for each FBG sensor. Data processing for converting shifts in wavelength to strain changes was carried out using established methods reported in the literature (Kreuzer, 2006; Kurashima et al., 1993). The following expression was used to calculate the mechanical strain change derived from the combined strain–temperature arrays.ΔεM=1κεΔλλoSκTΔλ/λoTκTTαconcΔλ/λoTκTT

This equation accounts for several effects: total (raw) strain, changes in the refractive index of the glass due to temperature, and thermal strain measured with the loose tube temperature compensating sensors. The data output by the processing unit (and reported herein) have been translated to mechanical strain by correcting for temperature and separating the influences of thermal and mechanical strain variations.

4.3 The modelled system

The framework for the modelled system used in this case study is presented in Figure 1. Note that for clarity only selected entities are presented in the diagram. The modelled system is composed of two types of monitoring assemblies, MA_Beams and MA_Deck. They are associated with the structural assemblies TY_Beams and Deck, respectively. One instance of a sensor system is instantiated per each TY beam which has both a DFOS and a PFOS sensor system that are linked with a single pre-stressing strand. Each DFOS and PFOS sensor system consists of a sensor, a network communication element and a connection element. The monitoring assembly MA_Deck only has PFOS sensor systems. Various attributes are linked to each sensor system. Figure 2 presents sample attributes for monitoring assemblies, DFOS and PFOS sensor systems, and individual sensors. The modelled system was able to include a low level of detail because it would only be used for visualising overall sensor data, for which only the sensors have been modelled in the authoring tool. The acquired data from DFOS only include the readings and the relative distances at which they were taken, while the acquired data from the PFOS included the reading and a timestamp. The spatial and hierarchical attributes were inferred using the order in which the values are listed and information from the design documentation. Note that, for this case study, only data acquired by PFOS are presented.

4.4 Data visualisation and interpretation

The following section provides an overview of the data obtained from 7 d of continuous monitoring of the concrete deck, transverse ties and prestressed beams during deck curing (dates corresponding to 13 July 2015 up to and including 20 July 2015). Data were recorded every minute and a baseline strain value was taken at approximately 1 h following the completion of deck casting. These data were then incorporated directly into the developed BIM sensor elements and displayed on the 3D model to provide a complete visualisation of the strain changes throughout the entire structure over time.

Figure 7 shows the development of mechanical strains in the deck and the transverse ties over the entire 7 d curing period. Note that the reported values have been compensated to take into account strains due to thermal expansion and therefore the strains are assumed to be mainly due to concrete shrinkage. As expected, the strains developed in both the deck and ties exhibit a downwards trend and are negative, indicating compression due to the shrinkage of the concrete during curing. The deck appears to experience higher strains during curing and also fluctuates with diurnal temperature cycles as compared to the transverse ties. This is most likely due to the higher concrete pore water evaporation that takes place closer to the free concrete surface (top of the deck).

figure parent remove

Figure 7. Evolution of mechanical strains during first 7 d of deck curing for the mid-span deck and transverse ties (baseline = post deck casting/start of curing process)

To determine the effect of the net shrinkage that occurs in the deck and infill concrete on the prestressed beams, the sensor data for the beams were examined and are presented in Figure 8. Note that this figure depicts only the top and bottom sensors located at the mid-span of the beam. The main finding from the sensor data shows that, after 7 d of deck curing, the top fibre of the beam experiences net change in compression (approximately 50 microstrain) and the bottom strains fluctuate but eventually have no net strain change. Therefore, a permanent difference in beam curvature (corresponding to positive bending) is introduced as a result of this difference in top and bottom strains. This result is in accordance with the anticipated behaviour, as noted by Hendy and Smith (2007) for the effect of differential shrinkage between cast-in-situ deck and prestressed girders. It should be noted that the mechanical strains presented in Figure 8 do not include the additional strains introduced due to the added weight of the concrete deck (i.e. baseline of strain data was taken as the start of curing). This baseline was chosen in order to isolate only the effect of the deck curing process on beam behaviour.

figure parent remove

Figure 8. BM5 variation of top and bottom mechanical strains during deck curing (baseline = post deck casting)

Regarding the visualisation on the BIM model, an alternative scaled-up and simpler geometry has been used to visualise the PFOS sensor systems as presented in Figure 9. To visualise varying strains, a colour-coded scale has been used in the BIM models, which is depicted in gray-scale in the images presented here. The values of the strain attributes of each sensor entity have been linked with the material attributes. The corresponding material attributes for visualisation of monitoring data have been adjusted for the structural elements as well. As previously noted, a specific BIM model has been developed for each visualisation and analysed data set.

figure parent remove

Figure 9. BIM model of the deck at mid-span with integrated sensor data and displayed at the start of deck curing

The acquired sensor data, as presented above, can be included in the developed sensor entities and visualised directly on the BIM model to facilitate data interpretation. For example, prior to performing any detailed analyses, it is possible to inspect the BIM model directly and decipher the same trends that were previously discussed but across an entire structural element. In the case of the deck and tie elements, Figure 9 shows the increasing levels of compression developed in the sensor entities between the start of curing (13 July 2015) and the end of the measured curing process (20 July 2015). Note that only selected dates are presented. Similarly, the sensor data for BM5 can be visualised as shown in Figure 10. From this figure the same trend identified using Figure 8 can now be interpreted directly on the BIM model (i.e. no net strain change in bottom of beam and net compression induced in the top of the beam). This type of comparison demonstrates the immediate value of this approach as the visualised sensor data can be quickly used to identify important trends in structural behaviour prior to undertaking more detailed analyses.

figure parent remove

Figure 10. BIM model of beam BM5 with integrated sensor data and displayed at the end of deck curing

By combining the entire monitoring data set on the BIM model as presented in Figure 11, general trends can be identified across the entire structure at given points in time. In particular, it can be seen that the sensors in the quarter-span deck and transverse ties also register a net compressive strain change during deck curing. Likewise, similar to the behaviour of BM5, the other monitored beams BM1, BM2 and BM4 show negligible changes in bottom strains and permanent compressive top strains (on the order of approximately 50 microstrain) following 7 d of deck curing. Based on this general visual assessment of the distribution of strains, it may be inferred that the shrinkage strains induced during the curing of the concrete deck appear to be fairly uniform across the top portion of the entire bridge structure. The actual measured behaviour based on this visual inspection has been verified by performing a more detailed analysis using plots similar to Figures 7 and 8. Adding the sensor data into the BIM model has effectively transformed the model into a ‘living’ structure which enables different practitioners to evaluate its performance during the different stages. The data set could easily be obtained from the sensors and visualised in the BIM model at any given stage following construction completion and hence help to inform decision makers throughout the structure's life cycle.

figure parent remove

Figure 11. Complete BIM models incorporating monitoring data from start and end of deck curing

There is a lack of provision to employ the BIM approach fully for structural performance monitoring. Most notably, the data model standards are not yet sufficient to describe monitoring systems and processes, and there are no formalised directives to manage and visualise sensor data in a BIM environment. The approach presented in this paper further advances the development of BIM provisions for structural performance monitoring. It formalises a process to model monitoring systems and to manage and visualise monitoring data.

Data acquired during the casting and curing of a bridge concrete deck have been used as a case study. The semantically rich BIM models developed as part of this work serve primarily as a visualisation tool for asset managers and engineers. The case study showed that they can be used to facilitate more streamlined approaches to structural monitoring and data management, and allow for a quick interpretation of general trends in structural behaviour. However, the interpretation of the sensor data for the purposes of making decisions for long-term management strategies and safeguarding still requires the skills of an experienced and competent professional. Note that visualising monitoring data directly on BIM models should not replace traditional visualisation and interpretation methods using time-history charts and graphs. Both methods have their own benefits and disadvantages and are effective in different scenarios. Additionally, a BIM model that incorporates monitoring data that capture the structural performance of a bridge up to the end of its construction, would also become an invaluable component of the handover documents required as part of the commissioning process.

As noted in the paper, different monitoring objectives and data would require different modelling, management and visualisation requirements. In this sense, further work should be focused on finding and tackling challenges presented by managing and visualising data acquired during different stages of the asset's life cycle. The visualisation of information derived from the initial data set could also be developed, for example, by including and visualising derived stresses and displacements and the associated load cases directly on the BIM models, which would be very useful when compared to the inspection idea, which could also be incorporated in the model.


The authors gratefully acknowledge the Engineering and Physical Sciences Research Council (EPSRC) and Innovate UK for funding this research through the CSIC Innovation and Knowledge Centre (EPSRC grant reference number EP/L010917/1); the on-site assistance of Jason Shardelow, Peter Knott, Hyungjoon Seo of CSIC and Jules Birks of Mott-MacDonald (formerly of CSIC); the technical assistance in sensor development and procurement of Cedric Kechavarzi and Philip Keenan of CSIC; James Oliver, Matthew Timmis, Brad Stanaway and Phil Holland of Laing O'Rourke; and Ruth Platt and Mike Henwood of Atkins for providing their invaluable support for this project.

Additional data related to this publication are available at the University of Cambridge data repository:


linear coefficient of thermal expansion of concrete (per °C)


change in mechanical strain


change in relative wavelength of strain sensor


change in relative wavelength of temperature compensating sensor


gauge factor, provided by strain sensor manufacturer


temperature compensation constant, provided by sensor manufacturer


change in refractive index of glass


Cited By

Related content

Related search

By Keyword
By Author

No search history

Recently Viewed