Rapid deployment of a WSN on the Clifton Suspension Bridge, UK Open Access

The maintenance of ageing civil infrastructure is a concern the world over, such as in the UK, where an ‘asset time bomb’ has been described (Thurlby, 2013; Thurlby and Rimmel, 2015). Structural health monitoring (SHM) is necessary to make estimates of the structural condition and validate structural models. Various reviews of bridge monitoring approaches have been published recently (e.g. Andersen and Vesterien, 2006; Catbas et al., 2013; Middleton et al., 2016; and Vardanega et al., 2016). Webb et al. (2015) presented a categorisation framework for classifying SHM deployments for bridges, suggesting that bridge monitoring systems can fit within one (or several) of the following: (a) anomaly detection, (b) sensor deployment studies, (c) model validation, (d ) threshold check and (e) damage detection.

For bridge structures, visual inspection to assess structural condition remains the most common form of monitoring (e.g. McRobbie et al., 2015). Various studies have shown that visual inspection delivers inconsistent outcomes, particularly in the recording of defects (e.g. Lea and Middleton, 2002; Moore et al., 2001). Bennetts et al. (2016) (after interviewing 11 bridge management professionals) concluded that the use of visual inspection data in asset management decision-making is ‘heterogeneous’ within the UK industry. It has been hoped that improved technology will eventually replace (or at least supplement) visual inspection techniques (e.g. McRobbie et al., 2015).

This paper reports on the rapid deployment of a wireless sensor network (WSN) on the Clifton Suspension Bridge (CSB) in Bristol in the UK. The study is essentially a ‘sensor deployment study’ (cf. Webb et al., 2015). This iconic structure is the subject of ongoing research such as the vibration response caused by pedestrians and wind loading (Macdonald, 2008; Nikitas et al., 2011). However, the structural response has not previously been correlated with vehicular use (e.g. Macdonald, 2008), which this sensor deployment aims to address. The top of this bridge is not an easy place on which to deploy a WSN thanks to its structure of iron and masonry, and much was learnt about the benefits and limitations of the deployed technology during this project.

SHM using WSNs for bridge structures has been the subject of much recent research (Hoult et al., 2008, 2009, 2010; Lynch et al., 2006; Rodenas-Herráiz et al., 2016; Stajano et al., 2010; Webb et al., 2014), with a number of large-scale deployments (e.g. Jang et al., 2010, 2011; Kurata et al., 2013; Lynch et al., 2006). Another technology much less discussed in the field of SHM is the use of application interfaces (APIs) and open-source software (OSS) for data management. Many mature and powerful OSS packages exist for collection, transmission, processing, storage and visualisation of data. In this study, the authors demonstrate how, by using APIs to combine OSS and WSNs, a powerful SHM ‘dashboard’ can be built quickly and cheaply.

The aims of the study were to

• attempt a rapid SHM deployment for short-term monitoring;

• integrate wireless SHM and open-source data management systems;

• use existing monitoring systems to gather information about bridge use to inform structural models; and

• correlate structural data and traffic management data to explore the use of structural sensors for monitoring bridge use.

To reduce system costs, off-the-shelf sensing hardware was incorporated into an open-source data management and visualisation platform, assembled specifically for this project and requiring software and hardware integration. Time constraints on the project meant that it was necessary to minimise the amount of hardware and software development, and doing this while still producing a feature-rich and intuitive system required the integration of a number of different subsystems. Much of the novelty of this paper is based on the development of this platform and the use of ‘big data’ management techniques to deliver a functional SHM system.

A key requirement for the rapid development of the system was that the wireless hardware components functioned ‘out of the box’ while still providing flexibility and the opportunity of integration into a data management system. Lord MicroStrain V-Link-200 and WSDA-Base-104-LXRS were selected, although alternative systems were considered.

V-Link-200 is an eight-channel, 18-bit remote analogue-to-digital converter (ADC), which connects wirelessly to the WSDA-Base-104-LXRS universal serial bus (USB) gateway. The gateway sits at the centre of a star network of ADCs, manages time synchronisation, collects the data generated by the remote sensor nodes and passes it to a personal computer, through a USB. The wireless communications are based on the Institute of Electrical and Electronics Engineers 802.15.4 radio-frequency (RF) standard, operating at 2·4 GHz. The 802.15.4 standard is designed specifically for low-power applications, increasing the sensor node battery life.

V-Link-200 (Lord MicroStrain, 2017a) provides a direct-current energisation power supply for structural sensors. The sensor node is internally powered by four lithium ion AA cells; however, it can also accept an external power supply, to which two 12 V, 12·0 Ah valve-regulated lead acid (VRLA) batteries were connected. Desktop experimentation suggested that the wireless nodes would draw 37 and 31 mA depending on the number of sensors attached, giving a theoretical continual running time of just under 30 d.

The sample rate of V-Link-200 can be configured. Macdonald (2008) identified 27 modes of vibration with natural frequency below 3 Hz, which are more than enough to characterise the global dynamic behaviour of the bridge. However, to capture fully the local transient dynamics due to sudden changes in loading as vehicles drive onto or off the suspended span, a higher frequency range was captured in these experiments. A rate of 64 samples per second was selected initially (giving visibility of frequencies up to 32 Hz) with the wireless system providing the ability to increase the sampling rate to 256 Hz should it be required. The sample rate of the ADC has a significant impact on the power consumption of the wireless node. Much power is used during the sampling of sensors and the wireless transmission of the data, making a low sampling frequency desirable for maximising battery life. Power profiling at a range of sample frequencies suggested that by halving the sample rate, the battery life could have been increased to 50 d. There is also a finite limit to network bandwidth, with a higher sample rate using more network capacity. In the deployment of six sensors, the network bandwidth allowed for a maximum sampling frequency of 256 Hz.

Integrating off-the-shelf hardware into an OSS platform requires the proprietary equipment to provide some software ‘handles’ (referred to as an API) through which it can be controlled or queried. To display real-time measurements, the sensor API must make these data available directly after the reading has been taken. The data must be presented in an open format that does not require proprietary software. As well as providing an interface to gather data, APIs can also include mechanisms for manipulating hardware. Software able to configure, start and stop the measurement devices will significantly reduce the amount of manual set-up required and allows automatic recovery to be built into the system, increasing overall system availability. Lord MicroStrain’s MicroStrain Communication Library (MSCL) API (Lord MicroStrain, 2017b) provides this functionality.

V-Link-200 required ‘ruggedising’ before installation into a site environment. An IP65-rated plastic enclosure was used to house each V-Link-200 with its two VRLA batteries. IP67-rated connectors were used to simplify the connection of the structural sensors while on-site, removing the need to connect screw terminals while in a challenging or enclosed environment. Photographs of the produced sensor node are given in Figure 1.

Accelerometers and displacement transducers were connected to the wireless sensor nodes. The accelerometers were single-axis strain gauge-based devices with a full range of 10 m/s² – namely. ARF-10A from Tokyo Sokki Kenkyujo (2017a). The accelerometers were powered from the 4 V excitation supply provided by V-Link-200, while their outputs were fed directly into differential ADC inputs. The full 10 m/s² range of the accelerometer is visible at a resolution of 5·2 × 10⁻⁵ m/s², but with a noise floor of up to 5·2 × 10⁻³ m/s² root mean square (RMS).

The displacement transducers used were the potentiometer-based PT8101 from Celesco (2017), with a physical range of 500 mm and resistance of 0–5 kΩ. The power consumption of the sensor was reduced by incorporating it into a potential divider circuit. This gave visibility to the complete 500 mm range of the transducer at a resolution of 1·9 µm and a noise floor of around 50 µm RMS.

Integrating structural sensors into open-source data management platforms enables great flexibility for data collection, storage, retrieval, processing and visualisation, and with much of the software being free, it is possible to build sophisticated, secure and feature-rich systems at a reduced cost.

The software platform produced for this project comprised four main components

• the Lord MSCL API, which configures the wireless sensors and collects data

• a message broker (Kafka) that simplifies the movement of data

• a ‘time series database’ (InfluxDB), which provides long-term storage for the data

• a web-based data visualisation interface (Grafana)

A high-level illustration of the system is given in Figure 2.

The system is roughly divided into the ‘outstation’, running on a computer on-site, and the ‘instation’, which runs on a server housed in one of the university computer labs. The outstation manages the sensor nodes, collects the data and then relays the data to the instation, where the data are stored, processed and distributed to users. Dividing the system in this way reduces the outstation hardware requirements, increases the computing resource available to process the data and improves the robustness of data access.

The only software running at the monitoring site is that concerned with the collection of the data from the sensor nodes and then its publication over a network. A software package developed for the project used MSCL to interface with the wireless ADCs. When launched, it configures the network of sensor nodes, starts sampling and then transmits measurements back to the instation by using a message broker ‘client’ library. The hardware required to perform this can be small and inexpensive. In this deployment, it was run on an off-the-shelf laptop. However, it would be possible to use a low-cost single-board computer.

The use of software libraries reduces the work for the application developer. For example, MSCL manages the synchronisation of measurements automatically without any code having to be written to perform this task.

Each time that a measurement was received from a sensor, the software processed it, encapsulating the data so that these can be sent over a network to the instation. Rather than sending measurements directly to a destination, the system used ‘message-oriented middleware’ (also known as a message broker) to transmit the data. The message broker acts as a post office, allowing the data-generating component (the outstation software) to send all messages to a single location independent of the recipient. The broker then forwards those data to any application that has requested the stream (the instation software).

Referred to as the ‘publish–subscribe’ model, the message broker approach allows the ‘decoupling’ of the data publisher and subscriber, meaning system components can be added without existing elements requiring reconfiguration. For example, if a component capable of performing machine learning on the data were to be added, with traditional messaging techniques, the data-generating element would now have to send two data streams and be reconfigured with the address of the new component. When using a message broker, no change is required to the data generator, and the new component simply subscribes to the data that it requires.

Many different message broker platforms exist, with open-source Apache Kafka being selected for use in this project. Kafka can handle a large message throughput with very low latency, making it highly scalable and allowing a large number of sensors (many thousands) to be added to the system without requiring any modification to the platform architecture. Kafka can also provide redundancy and fault tolerance, with data being duplicated across multiple physical servers (referred to as a cluster).

Independent of the message handling technology used, for the streaming of live data, it is necessary to have a permanent communications link between the outstation and instation. For this project, a typical household asymmetric digital subscriber line (ADSL) connection was sufficient, although any form of Internet Protocol connection could have been used.

A considerable number of different database technologies exist, with a range of different strengths and limitations. The nature of the data being gathered here meant that the use of a time series database, where all data are stored along with a timestamp, was well suited to the application. The open-source database InfluxDB was selected. Like the Kafka message broker, this is completely free and designed to provide high availability. Freely available software exists for interfacing between the Kafka message broker and InfluxDB, so very little code had to be written to integrate the two components.

Presenting the sensor data in a way that allows users to make sense of these is important, with the creation of a data dashboard being one of the key aims of the project. Again, there are many different software packages that can deliver these sorts of dashboards, with many being either open source or free to use. Classically, a dashboard would be presented on bespoke hardware running software specific for the task, but this limits user access and requires the purchase of new hardware. Now data visualisation commonly is done through interactive web pages, meaning information can be displayed on a device connected to the Internet with web browser capability.

One such web-based dashboard is the open-source Grafana software. Designed specifically for visualising time series data, Grafana allows navigation of both historic and real-time data and integrates easily with InfluxDB.

For larger deployments, the different system components would be hosted on different physical servers. This was not deemed necessary for this project, however; instead, the complete instation system ran on a single server housed in the University of Bristol High-performance Networks computer lab. Had this server proved insufficient, the system’s modular nature meant that any of the software components could have been ported to different hardware.

Modularity is provided by specifying the message structure that components use to communicate and ensuring that these messages can pass between servers. This means that the same architecture could be used to provide a commercial deployment, which might be spread across multiple physical servers, multiple physical locations or even hosted in ‘the Cloud’. Modularity improves system scalability and the availability of the backend software.

The system could only monitor and had no ability to actuate an effect in the real world. This lowers the potential severity of a cyberattack, highlighted by principle 10 of Stajano et al. (2010: p. 881): ‘Your risk rating must be a function of the use to which the network will be put and of its side effects on the environment’. This does not remove the threat of attack completely, however, and system security is still crucial if the deletion or manipulation of data used for making safety-critical decisions is to be prevented and potentially sensitive data kept out of malicious hands.

As well as the encryption provided by a University of Bristol virtual private network, each of the software components used in this deployment can be secured with either encryption or user identification. Kafka can be configured to use transport layer security, and Kerberos user identification to prevent man-in-the-middle attacks, while InfluxDB and Grafana can both be configured with username and password identification to prevent unauthorised access to the data. Although these capabilities exist and can be easily configured, not all these measures were used for this deployment as the instation server was hosted within the University of Bristol secure network.

The CSB was chosen as the location for the deployment of the WSN. The prominence of the bridge means that a significant amount of research has already been done on it, and this informed the system deployment. The system could also be evaluated against previous monitoring systems. The size and structure of the bridge also makes it convenient for study: small enough that the complete bridge can be monitored and understood, but large enough and flexible enough to exhibit some interesting dynamic behaviour (Macdonald, 2008; Nikitas et al., 2011). The CSB’s function as a toll bridge means that existing traffic monitoring infrastructure might provide information about vehicles. Research on the bridge continues, and this will be aided by the data collected during this deployment.

The CSB spans the Avon Gorge, some 214 m, connecting West Bristol with North Somerset. Since its completion in 1864, the bridge has carried vehicles and pedestrian traffic, and it remains one of the key routes into the city, with up to 3000 vehicles crossing an hour during peak times and 20 000 through the course of a day. The bridge supports bidirectional traffic with one lane in each direction, as well as two footways, one down either side, separated from the carriageway by a pair of 914 mm high iron stiffening girders running its complete length. As well as a conduit for vehicles, cyclists and pedestrians, the iconic nature of the bridge means that it is a tourist destination, significantly increasing pedestrian flow. For a complete description of the structure of the CSB, refer to Barlow (1867).

Tight budget and time constraints meant that the number of sensors had to be kept low, making sensor positioning crucial if the system was to collect useful data. Macdonald (2008) identified that all the deck vibration modes below 3 Hz could be detected at a location 26·8 m from the midpoint, and so this was selected as the location for one of the accelerometer cross-sections. A second accelerometer cross-section was selected at the Leigh Woods end of the bridge deck as it was believed that this would show the greatest transient response from vehicles entering and exiting the suspended deck span. At each cross-section, two accelerometers were positioned, on either side of the bridge deck, so that both vertical and torsional motions could be measured. Alongside the accelerometers, two displacement transducers were also fitted at the Leigh Woods end to allow the vertical distance between the suspended bridge deck and the fixed abutment to be measured on either side of the deck. The sensor nodes were identified by the nearest vertical suspension rod. Therefore, the node 26·8 m from the midpoint was referred to as rod 11LW, while the node at the Leigh Woods end was rod 40LW. Figure 3 shows an illustration of the deployment locations of the sensors.

When considering the deployment locations for wireless sensors, it is important to take into account the positioning of the wireless sensor gateway. The 2·4 GHz radio band cannot propagate effectively through masonry or metal, which means that in a star network topology, where each sensor node must communicate directly with the gateway, each must have a clear line of sight between its antenna and the antenna of the gateway. Equally, lower-frequency bands, such as 915 MHz, are attenuated significantly less by these obstructions, although they do provide a lower bandwidth.

Selecting an appropriate location for the gateway is an important system design decision. If a poor decision is made and the gateway placed in a location with only intermittent communications with the sensor node, failed transmissions might make the data unusable. Also, for the gateway to be able to relay data to the instation, it requires a robust Internet connection. The only available enclosed location close enough to be bridge with a permanent Wi-Fi connection (used to communicate with the instation) and power supply was the staff toilet at the Leigh Woods end of the bridge. The small form factor of the sensor gateway hardware allowed it to be installed here without interfering with the use of the facilities.

Predicting the exact range of a wireless communication link is difficult, as it is highly dependent on the surrounding environment. The Lord MicroStrain website gives a maximum wireless range of 1·5 km; however, this is reduced significantly (typically to 500 m) by any obstacles or radio interference. The CSB contains a large amount of masonry and iron, making it hostile to radio signals. Although it is possible to model radio propagation, the way that radio signals interact with objects in the environment means that predicting signal strength in a specific location can be difficult. Effects, such as ‘multipath-induced fading’, are highly dependent on the arrangement and composition of surrounding objects, so any model attempting to predict this must contain an extremely accurate representation of the local structure. Equally, the environment is not static, containing moving vehicles, people and variable weather conditions, and so it changes with time. Another hurdle to predicting message delivery rate is that the frequency of the radio signal (2·4 GHz) is in an unlicensed band of the radio spectrum, and as a result, it is used extensively for wireless communications (such as Bluetooth and Wi-Fi), and these frequencies can become very cluttered, potentially causing swamping of the sensor node transmissions. Although techniques such as ‘channel hopping’ can improve delivery rates in congested RF environments, by changing the frequency used for message delivery, this was not available on the nodes used for this deployment.

All these factors combine to make predicting wireless propagation mathematically very difficult; this means that to be confident of effective deployment, a thorough RF survey of the location should be performed, ideally at a range of different times of day and under different weather conditions. Unfortunately, the rapid deployment meant that there was insufficient time for a complete survey using specialist equipment; instead, a more simplified experiment was performed using the wireless sensor nodes and gateway positioned as they might be for a final deployment. The system is able to report and record the received signal strength indication (RSSI) between devices in real time, so this gave confidence in the function of the final system, although it was not able to provide all the information a full survey would have done.

It is always important to consider carefully the location where the equipment will be installed, particularly when retrofitting onto existing infrastructure. Normally, this would require at least one site visit to inspect the installation location. However, the CSB is such a well-studied structure that enough information could be gathered from existing research material. The sensor nodes were to be installed below the bridge deck, access to which requires the closure of a footway. Hence, limiting the number of times access was required was desirable.

Full installation of both the sensors and the wireless gateway was completed in a single day by a team of five. Work was carried out as per the method statement, produced as part of the ‘risk assessment and method statement’ (RAMS) documentation. Complete RAMS documents were signed off by the bridgemaster well in advance of the installation being carried out.

The system would perform only if a consistent wireless connection was achieved between the gateway and wireless sensor nodes. Even a slight change in antenna location can impact significantly the RSSI, and it is therefore beneficial if the installer of the aerial has access to a live feed of the RSSI values while ‘micrositing’ the antenna location. The installer must therefore be in receipt of live information gathered by the gateway, meaning the gateway must be installed, connected and transmitting data. The software platform developed for this project was able to deliver this functionality from the moment that the gateway was configured and connected to the Internet, meaning that the installer of the antenna was able to get the RSSI information streamed directly to a smartphone where the installation was happening, 64 times a second. This significantly aided installation, helping to ensure that the locations selected for the antennae provided the best available signal strength.

Live data can also benefit the installer tasked with fitting the structural sensors, as they can see in real time the data being generated by the sensor (often this speeds up commissioning), and this can reduce the required size of an installation team as it removes the need for someone at the instation to confirm that a sensor has been successfully installed. This advantage is particularly pronounced when the installation is being done for the first time.

The most significant drawback of a WSN is the requirement for batteries to support the operation of the system. The predicted battery life of 1 month turned out to be extremely accurate, with the batteries on the first of the sensor nodes expiring 33 d after installation.

In many WSN deployments, it is possible to incorporate technology into the sensor node that allows it to generate electricity locally, most commonly solar or wind power, and in these situations, a wireless device can last years between servicing. In situations where energy harvesting is not possible, battery life expectancy often puts a cap on the maximum possible time between visits to the sensor. Battery replacement can be done routinely, although optimising this process requires visibility of the remaining charge. Efforts were made to capture this information but were untested, and the battery failure at rod 40LW came without warning.

The other significant downside of a wireless deployment is the risk of dropped messages and the effect any failure of the transmission system has on the value of the collected data. The efforts detailed earlier could not achieve complete reliability. An initial extremely poor transmission success rate was improved by increasing the gain on the antennae; however, the best that could be achieved was 91·64% across the two sensor nodes during the final week of the deployment. A fuller explanation of the antenna replacements is given in the following section.

It was necessary to make continual improvements and adjustments to the system, even once it had been deployed. These took two forms: (a) adjusting the antennae on the wireless sensor nodes and (b) updating the software to add desirable features.

With the sensor nodes installed below the bridge deck, the antennae had to be connected by RF extension cables so that they could be brought above the deck and attached to the bridge hangers. Limitation in where nodes and gateway could be installed meant that the path of the transmission had to pass through the arch of the bridge tower, which is also the route of the carriageway. This meant that the RF signal strength was impacted by the number of vehicles crossing the bridge at the time, and so the number of dropped messages would sometimes rise at times of peak traffic. The system reports and records the RSSI of every message received; at quiet times, a strength of −70 dB was common, while at peak times, this could drop to −75 dB, sometimes causing message transmission to fail. If the RSSI dropped below −80 dB, very significant message drop would occur, possibly up to 70%.

During and directly after installation, the reliability of message transmission seemed very good, with 99% of transmissions successfully received in the first 5 h. After this period, however, the drop rate increased significantly, and by the following morning, only 52% of measurements were received across the two nodes, with the node furthest from the gateway (rod 11LW) suffering particularly badly at 35%. To improve this performance, the antennae on both sensor nodes were replaced with ones with a higher gain. The antenna on the nearer node to the gateway (rod 40LW) was changed from 3 to 6 decibels relative to isotropic (dBi), while on rod 11LW, a 3 dBi antenna was replaced by a 9 dBi alternative.

At rod 11LW, replacing the antenna had an immediate positive impact, with only 119 995 messages getting dropped over the next 3 d, a success rate of 99·2%. The impact on rod 40LW, however, was not so pronounced, with a successful delivery rate of 93·1% in the same period compared to 92·2% in the 3 d before. The link with rod 11LW remained more reliable for the remainder of the project despite efforts to replicate its strong performance at rod 40LW. An attempt was made to replace the 6 dBi antenna on rod 40LW with a 9 dBi alternative; however, this had such a negative impact on the transmission rate that the replacement was aborted and the 6 dBi antenna reinstalled.

The gateway was fitted with a directional antenna, while the sensor nodes had omnidirectional antennae. The use of omnidirectional antennae meant that rather than focusing the energy of transmission towards the gateway, it was broadcast uniformly around the sensor, resulting in much of the energy not being directed towards the gateway. These antennae were used at the sensor nodes to limit the aesthetic impact of the installation. However, it is believed that had directional antennae been used transmission, success rates would have been improved.

It was also necessary to improve and modify the system software continually, usually to add extra functionality that was decided would be of benefit. As an example, the rapid development of the system meant that the initial version of the outstation software did not transmit diagnostic messages sent by the wireless nodes, and so this was added through a software update to the outstation. Remote access meant software updates could be performed remotely.

The modular platform meant that when alterations were required, it was normally necessary to change only one component, and as long as the interfaces between this component and those it interacted with remain unchanged, then the rest of the system could be left to run without requiring modification or restart. This was the case when adding the functionality to collect and store diagnostic messages. Here, only the software running at the gateway had to be modified. The diagnostic data could be passed to the database using the same API as had been used for the structural measurements, and so no modifications were required to the instation software. As well as speeding up the development of the software, the modularity reduced the downtime required by an upgrade as only the component requiring modification needed to be restarted.

The project also collected data from the existing bridge traffic management systems. This included

• vehicle counts from the toll barrier system; and

• vehicle axle weights from the weighbridge devices on the approaches to the bridge from each end.

Ongoing work will compare these quantitative data with the structural sensor measurements to understand the effect that physical loading from vehicles has on the bridge.

An experiment was performed where a vehicle of a known weight was driven multiple times over the bridge at a range of speeds. The test vehicle was fitted with a wireless sensor node and accelerometer so that its vibrations could be recorded synchronously with the structural data from the bridge. This relates to ongoing research on the identification of bridge modal parameters from moving load excitation (Liu and Macdonald, 2016; Liu et al., 2017). Toll barrier data were used to suggest a time when there would be very little other traffic, so that the tests could be conducted in the absence of any other vehicular loading.

This experiment leveraged the capabilities of the wireless sensor system, with the real-time streaming of data from a moving object not possible any other way. A fuller description of this experiment, along with analysis of the data generated, will be given in a future publication.

An example of the data generated by the system is available in comma-separated value (CSV) format (Gunner et al., 2017), alongside the calibration factors. The complete system was calibrated in a laboratory before and after deployment.

All data gathered during the deployment are stored in InfluxDB. With access to the InfluxDB API, a researcher can poll the database and specify precisely the data they want – for example, by running the following Linux command

This returns the requested section of the data in a JavaScript Object Notation (JSON) format, which can be easily interpreted by software. The response from the above command would be

These API hooks allow the system to be easily added to and enhanced as more sophisticated techniques for processing the data are developed.

Grafana provides an interface that integrates historic and live data, updating in real time as new data are saved to the database. Dashboards can be generated and customised without writing code, and stored data sets can be presented alongside one another for comparison. Two examples of dashboards are shown in Figure 4, giving examples of how structural data can be compared separately or alongside the vehicle monitoring information – for example, the individual axel weights of vehicles.

System diagnostic information is also stored in InfluxDB, and so this can be accessed through the API or visualised with Grafana. Deployment sensor node diagnostics were transmitted by each node every 30 s, while others were calculated on the server. Figure 5 shows a diagnostic dashboard, giving information, including node temperature and message retransmission count.

At times of very low traffic volume, the response of a single vehicle can be easily picked out, and much information can be inferred intuitively. Figure 6 shows two such traces.

One example of data that can be picked out is the vehicle direction of travel. Looking at Figure 6(a), as a vehicle arrives on the Clifton end of the bridge deck, small vibrations are detected at the opposite end of the bridge, rod 40LW, where accelerometers are positioned. The vibrations build up as the vehicle approaches the sensor location, and then as the vehicle leaves the bridge deck there is a large vertical acceleration, followed by decaying free vibrations. In Figure 6(b), the acceleration response at 40LW caused by a vehicle entering the bridge at the Leigh Woods end appears similar but in reverse. The key difference is that, since the vehicle enters the bridge at the sensor location, there are no responses before the large downward acceleration when the vehicle first arrives. The vibrations then decay as the vehicle moves away and they are already small at the start of the free decay when the vehicle has left at the Clifton end.

Inferring vehicle direction from the bridge deck displacement data is similarly intuitive. Figure 6(a) shows that when a vehicle enters the bridge at the Clifton end, the Leigh Woods end starts to rise slightly. As the vehicle approaches the Leigh Woods end, it drops. The maximum downward deflection occurs just before the vehicle leaves the bridge, at which time the deck snaps back up, leaving some residual free decay vibrations. In Figure 6(b), the displacement caused by a vehicle entering from Leigh Woods is similar but in reverse. The deck drops sharply as the vehicle enters the bridge and then rises above the previous unloaded position as the vehicle progresses towards the Clifton end.

Other information about a vehicle can be inferred, such as its lane discipline, visible in the difference between the north- and south-side displacement transducers.

Mathematical analysis of the data – for example, relating the data to models of the bridge – is currently underway. The data have already been as part of a research project at the University of Bristol analysing the free decay vibrations of the CSB (De Lord, 2017).

Even without being processed, the data can provide insight to bridge management. For example, in instances when a bridge is not fitted with traffic counting measures, an accelerometer might provide indicative information about traffic flow. Alongside the specific task of infrastructure management, the live data and the graphical dashboard are very visual and in some situations provide opportunities for public outreach.

Further insight has been gained by analysing the weighbridge outputs alongside the structural data. Figure 7 shows the responses to two vehicles along with the axle weights, as measured by the weighbridge device at the Clifton end of the bridge. The heavier vehicle induced larger displacements and accelerations of the bridge. The delay between the weight reading and the bridge response is due to the weighbridge being some distance upstream from the bridge deck.

As well as the effect that vehicles have on the bridge, it is also desirable to be able to identify other transport modes (namely, cyclists and pedestrians) and understand their effects. The social media app ‘Strava’ was queried to find instances of runners crossing the bridge. The structural response caused by one of these is shown in Figure 8.

Research is also being carried out into how the various data sources can be used to increase understanding of how the bridge is used and so better inform management decisions. For example, toll barrier data are often collected as part of the management of infrastructure but are rarely used as effectively as it could be. Future publications will explore these opportunities, ranging from simple analysis such as limiting the impact of bridge closures on commuter traffic to more complicated investigations, such as the possibility of predicting how a failure in another part of the road network might impact traffic on a specific bridge.

This paper has demonstrated that rapid deployment of SHM systems is possible when both the wireless sensor approach and big data management software are employed. While long-term WSN deployments do require regular changes of batteries or connections to a power source (be it mains or local generation), for short-duration deployments (such as this one), a single set of batteries can provide the required operation time. Use of off-the-shelf equipment and OSS was integral to deploying this system robustly, quickly and cheaply.

That it was possible to install the complete system in a single day with a largely inexperienced team and have live data being received from the sensors from the moment of installation was a pleasing achievement. The ability of WSNs and data management platforms to provide insight into the performance of infrastructure quickly and efficiently is demonstrated by this project. Achieving this with a limited budget would not have been possible without the use of OSS, as described in this paper.

Thanks go to the Clifton Suspension Bridge Trust and the bridgemaster, Trish Johnson, for providing site access and their support of this project. Thanks are also given to John Bennetts, Luca Lombardi, James De Lord and Yi Lui. Thanks also go to Andrew Ramage from Techni Measure. This project was supported by Engineering and Physical Sciences Research Council Grant EP/P511298/1 comprised in part by the project ‘Traffic Flow and Structural Monitoring: a Prototype Dashboard for the Clifton Suspension Bridge’.

The following OSS was used during the course of this project

• MSCL (Lord MicroStrain, 2017b)

• Apache Kafka (Apache, 2017)

• Kafka InfluxDB (2017) 

• InfluxDB (InfluxData, 2017)

• Grafana (Grafana Labs, 2017)

The data for reproducing Figures 4, 6, 7 and 8 are available to download from Gunner et al. (2017).