Long-Term Live-Load Monitoring: A Brief Discussion

Often, the idea of field testing a bridge over the course of weeks, months or years has been proposed as a "Health Monitoring System". However, before installing such a system, the first question that should really be addressed in detail from the bridge owner's point of view is "what exactly do we want to know and why do we want to know it?" Just monitoring "health" may not really do anything useful for the bridge owner. Some sort of concrete decisions should be able to be made from any data that is collected.

One situation that seems to be occurring more and more is that "cutting edge" technology or "killer app" software is promoted for these types of tests, but the actual deliverables end up being something less than useful to the bridge owner. After a lot of money is spent on "whiz-bang" equipment and software, and while it may be "interesting" to the people implementing it, the bridge owner has to be able to use the overall results to help make short and long term decisions regarding the structure. Taking data because it will be "interesting" is good for universities, but often not very good for bridge owners who have a limited budget for maintaining hundreds or thousands of bridges. It can be thought of in the following manner: If a test is completed, the output from a sensor (say strain, deflection, vibration) needs to be translated into some kind of decision or policy regarding the structure. Having "interesting" data isn't enough.

Before looking into that issue, the difference between "Long Term Monitoring" and "Long Term Live-Load Monitoring" as defined for this discussion should be described. The primary differences between the two types of systems are the available sample rates and the long term stability of the sensors.

For this discussion, Long-Term Monitoring will refer to a system that is in place for weeks, months, or years and is designed to track parameters that might possibly be changing over time such as concrete creep, crack growth in reinforced concrete members, or rotation or tilting of piers. Parameters that change slowly over time are generally related to temperature and dead load effects. This type of system should be able to see any permanent deformations caused by catastrophic events such as earthquake or other impacts, but they will not capture the event itself. The instrumentation required for this type of testing must be stable, meaning that it doesn't "lose its zero". There are different types of instrumentation with these characteristics, including optical fiber and Vibrating Wire (VW) technologies. These types of systems can be set to trigger an alarm (such as calling the office PC or even someone's pager) if some of the measured parameter limits are exceeded.

One tradeoff that often comes with this stability is that slower sample rates must be used, typically once a minute, once an hour, or even once a day. For VW sensors, probably the highest reasonable sample rate, assuming that several VW sensors are attached to a particular system, is once every 30 seconds. This means that responses due to trucks or other live loads will not be captured simply because the sample rate is too slow.

Alternatively, "Long Term Live-Load Monitoring" alludes to a system that is recording the structure's response due to traffic and/or other types of live loads. Instrumentation will need to be restricted to structural members that undergo significant responses when a truck crosses the structure. So, for example, a large bridge, say one with a span over 200 feet, should only be instrumented on the deck support system if the live loads are to be measured. Putting gages on the primary members of a large structure is probably only going to measure very little live-load strain due to any given truck crossing. Compare this to a Long Term Monitoring System that can have the sensors attached to the primary members so that overall movement can be tracked with time.

The instrumentation, hardware, and programming for a Live-Load Monitoring System is generally several steps higher in sophistication and cost. A relatively high sample rate is required to capture live-load responses, typically in the 50 to 100 Hz range. A long-term live-load monitoring system therefore must have huge data storage capacity, or be sophisticated enough to only store measurements caused by events of interest, or have enough processing capabilities to perform all of the data processing in real time such that only the final reduced data is stored. Storage of interesting data is feasible but there are numerous challenges related to setting a reliable trigger signals for starting and stopping the data storage. Typically, what happens is that the system is constantly measuring numerous sensors at this high sample rate but only storing the data in a short-term buffer. When a trigger event occurs, possibly a stress level or a switch closure from a sensor on the roadway or more sophisticated device, a block of data is written to a more permanent type of data storage. While a system of this type greatly reduces the amount of stored data compared to continuous recording, a large quantity of data can still be generated. The task of retrieving the data from the monitoring system is feasible but not trivial. Obtaining the desired trigger level is important as well as the timing of the trigger with respect to the captured data block. In addition, a considerable amount of testing and programming is required to obtain a reliable trigger scheme and this is generally site specific. Hardware designed to perform all of these tasks are relatively expensive.

With sufficient money and effort, the data acquisition problems can be solved so that good relevant data is obtained. The next problem to solve then is what to do with the data. What is to be extracted from the data? Who is going to do it? How often and for how long? Live-load response histories may provide some interesting pictures and indicate how a structure is performing but without accurate knowledge of the applied load, the response histories have little value. If one has a strain history but no loading information, what can be done? While this may be "interesting" from some research point of view, the actual bridge owner really can't do very much with such information.

This of course, leads to the question of what will it take to capture the required load information such as axle spacing, axle weights, precise position and speed of the vehicle, and which lane it is in. The answer to this question is that it will take a lot of money and a lot of field upkeep and maintenance to capture all of this information. Basically, the type of equipment used for this is referred to as "Weigh In Motion" or just "WIM" equipment. The authors of this paper spent two years doing exactly this type of project, and while feasible on a short-term basis at a particular site, any longer-term solution was judged to be quite difficult and expensive, but not impossible.

Rather than trying to capture complete records of each truck passage, a more realistic goal of a long-term live-load monitoring system is to process the data in real-time and provide only the reduced data. For example, accelerometer-based systems are available that will monitor vibrations in several of the bridge's members. The basic idea is that an initial "signature" (perhaps amplitude or frequency content of the member's ambient vibration) is acquired from the member in question and if it appears that this signature changes over time, then this might indicate that something has changed. This change could indicate some sort of damage, so then an alarm can be sent and an inspector dispatched to the site. While it's very difficult to determine from acceleration measurements only what exactly caused the change in response, at least the inspection process will have been initiated.

Another reason this type of system may be fielded is concern about fatigue monitoring in particular members or connections in a steel structure, therefore, one would like to know what stress ranges they are undergoing on a daily basis. With this information, a remaining fatigue life can be estimated and/or retrofit or replacement can be prioritized. Typically, something called a "rainflow" algorithm running inside a datalogger is used to count strain (stress) cycles. The advantage to this approach is that very little information is actually stored, just the number of times each stress range has been reached, meaning that very little hardware memory is required. One of the problems associated with this approach is that the measured stress may not be representative of the actual peak stress. Is the sensor located at the critical point and is the orientation of the sensor inline with principle stresses? Also one must assess how representative the recorded stress cycles are to the past and future stress cycles prior to calculating the remaining fatigue life. Again it is important to note that all of these long-term results are obtained with little or no knowledge of the actual loads that generated the responses. Also, since fatigue is rarely an issue for concrete structures, this type of approach would probably not be useful for them.

After determining what we want to obtain from structural monitoring and what can be delivered, it is also important to address what the decision process will be once the results are in. What is to happen if we see that the apparent natural frequency of the bridge has shifted 0.25 Hz? What decisions will be made if stress cycle data indicates that a peak live-load stress of 5 ksi was achieved and a 160 cycles at 6 ksi were obtained during a month?

An alternate, or at least supplement, to long-term live-load monitoring is a controlled live load test. With this approach, generally more sensors are applied, and the measurements can be associated with a precise load application. The primary benefit of relating measured responses to a known load is that responses can be compared with theoretical values. Finite element models calibrated to represent the actual structural response can be used to determine critical responses at locations other than at sensor locations and load ratings can be obtained for vehicles other than the test vehicle.

From the above discussion it is apparent that "long term monitoring" and "long term live-load monitoring" do not achieve the same goals and one system cannot perform the functions of the other. A long term monitoring system cannot capture live-load responses because the sample rates are too slow. Alternatively, sensors used to capture live-load responses (typically foil strain gage-based sensors) are not stable enough to accurately measure slow responses due to temperature, creep, or foundation settlement. Output from live-load type sensors will drift over time such that the static responses from one period of time cannot be realistically compared with responses from another.

There are sensors available that attempt to bridge the gap between both long term dead load effects and live load effects, typically these are based on optical fiber technology. The idea is to get the advantages of both sensors, meaning good stability along with the capability of a high sample rate. It also appears that the instrumentation required to handle these sensors is still relatively expensive and often not real suitable for field use. Advances with this technology is constantly improving, however, it seems mostly suited to installation in new structures during the construction phase.

We've seen on many occasions where elaborate software and "cutting edge technology" hardware have a lot of appeal at first, but then once implemented we find that the same problems exist or that new problems have been generated. This doesn't mean to ignore things like optical fiber strain gages or wireless instrumentation, but the best question to ask for this kind of thing is "how many structures has this been implemented on?" If field installations have been made it would be worth while to contact the owner(s) to see if they are receiving what they wanted, and more importantly, find out if it is helping answer the questions that are being raised.