WIM Data Analysts Manual

Section 3. Steps for Data Validation and System Monitoring From Office

This section provides guidance and recommendations as to the steps to be taken by the Office WIM Data Analyst to validate data (Data Quality Control, or Data QC) and to monitor a WIM system's operation. Such steps include:

• Access the system from the office and perform initial real-time reviews.
• Perform reviews of canned reports to determine if a system is consistently operating properly, and if traffic is moving through the site within the lane lines at consistent speeds within the operating range of the system.
• Access the system from the office to perform system diagnostics if the data indicates that the system is not operating correctly.

WIM system site controller access display screens and setup procedures, as well as the application software provided by the WIM manufacturers for the user's Office Computer, vary by manufacturer. It is far beyond the scope of this manual to provide procedures applicable to each specific manufacturer or a manufacturer's specific equipment type or version of application software. The screen shots and sample report displays utilized in this manual are mostly taken from systems of two different manufacturers of WIM equipment. The intent is to provide general guidance on what to look for, as well as procedures to follow. Documentation on specific equipment and software provided by the WIM equipment manufacturer should be thoroughly reviewed by the analyst to determine how the examples in this manual can be applied.

The following recommendations on performing data QC and system monitoring do not include all possible procedures. The intent is for the novice analyst to use these recommendations as a starting point, and then develop additional procedures and checks as experience is obtained in working with the features of specific systems and Office Computer application software. For the experienced analyst, perhaps the following recommend procedures will provide additional tools to those already developed such that more thorough data QC and system monitoring analyses can be performed.

In addition, it is not the intent that the data QC checks monitor the fine-tuning aspects of a system's calibration. Calibration monitoring will be covered in SECTION 5. Calibration monitoring is only effective when using data from a system that is operating correctly and for which the traffic operating characteristics are normal. The intent of the data QC checks of each day's data file is to ensure that invalid data, whether caused by system malfunction or atypical traffic operating characteristics, is identified and flagged such that only data appropriate for its intended use is disseminated.

3.1. INITIAL REAL-TIME REVIEW

For agencies utilizing fully automated and unattended WIM data file download, calling up each system prior to the predetermined start of the download may not be feasible. In this case, if a system (or its communication link) is not operating properly, it will be evident following the download session. Otherwise, it is recommended that prior to downloading a significant number of data files from the system that it be accessed remotely from the office and spot-checked, as described below, to verify that the system is, in general, operating correctly. These checks are intended to identify any significant ongoing system problems without waiting for the data to be downloaded and reviewed, as well as to identify data files which contain significant amounts of missing and/or invalid data which do not need to be downloaded.

1. Does the onsite modem answer?
   
   If not, first ensure that the Office Computer's communication software and modem are properly configured. The quickest test for this is to call another WIM system similar to the one that is not responding. If it is confirmed that the Office Computer is communicating with other systems normally, a site visit is necessary to determine if the power or phone service is out, or if the site's modem is not working.
2. Does the onsite modem answer, but the system is not responding?
   
   If so, a site visit is necessary to check the modem configuration, and if the modem configuration is correct, the status of the controller.
3. Is the system's time and date correct? See Figure 18 for examples from two different systems.
   
   If not, correct time and/or date and determine if the affected files may still be of use for the intended purposes.

Figure 18. Screen shot. Site menu, time and date.

4. Do the stored files appear to be complete, and their file sizes appropriate? See Figure 19 for example.

For the site used in the example, it is typical for the weekday files to average about 500,000 bytes and the weekend files to average about 270,000 bytes, so these file sizes appear to be reasonable. The partial current day's file size also appears to be reasonable given it is for almost 12 hours. If the file sizes appear to be unreasonable, determine if the affected files may still be of use for the intended purposes. Unreasonable file sizes sometimes result from changes in the number of individual vehicle records that are being captured by the system, which may indicate that a system component is malfunctioning or that a system setting has changed. If it is obvious that a number of the daily data files are not usable, it may be beneficial to download only one of the files initially, in order to analyze and determine the cause of the problem.

Figure 19. Screen shot. Site menu, stored data files.

5. In viewing real-time vehicles, do their data elements appear to be reasonable for each lane (it is recommended that each lane be checked individually)?

Check the following items:

• Classifications
• Axle Spacings
• Speeds
• Weights
• System error or warning flag codes

Figure 20 displays a few records from a system's Lane 1 real-time truck traffic stream. In analyzing the records with "Ve.-Code: 15" (unclassified vehicles in the classification algorithm being used by this system), it should be obvious to the analyst that the three vehicles classified as "15" have spacings and weights which are typical of the Class 9's Type 3S2. This should quickly prompt a check of the system's settings for the classification algorithms.

Figure 20. Screen shot. Site real-time "View Vehicles" mode for system's Lane 1.

In reviewing the system's classification scheme algorithm setup displayed in Figure 21, it is evident that a system malfunction has occurred. This is a classification algorithm setup convention in which the two rightmost numbers for the axle distances (spacings) are decimal places (values in feet). What is supposed to be Type 9, the FHWA Class 9 - 3S2 configuration, is instead a Type 75, with some random spacing definitions. Since this system's classification algorithm does not include a Type 9, all vehicles conforming to the intended Type 9 axle spacing parameters are labeled Class 15 (unclassified). The next classification algorithm in Figure 21, shown as Type 14, is the Agency's Class 14 (FHWA's Class 9 - 32 configuration), which has maintained the correct axle spacing scheme.

Figure 22 displays an example of two vehicles with "Significant Weight Difference" warning flags. In monitoring all Lane EB#2 vehicles for a longer time frame the analyst notes that many or even all are flagged with this warning. For this system, this warning flag indicates that the left versus right sensor weight outputs of one or more of a vehicle's axles exceed a 40 percent difference. In examining the left and right sensor weight outputs, the left weights appear to be reasonable. However, the right weight outputs appear to be only about half of the left weight outputs. This should prompt a check of the calibration factors for obviously erroneous low values for this lane's right weigh sensor.

Figure 21. Screen shots. Menu screen displaying portion of classification algorithm entries.

Figure 22. Screen shot. Site real-time "View Vehicles" mode.

Figure 23 displays the menu "path" for this particular system to view the current calibration factor settings for the weigh sensor ("WIM Sensor 3") in question. The analyst should compare these factors with those on record to see if they are correct. If these factors are correct, additional diagnostics can be performed on this sensor as will be discussed later.

Figure 23. Screen shots. Site real-time menu screen displaying calibration factors.

This short term monitoring session of individual vehicles passing through the system in real-time is intended to catch only significant and ongoing problems with the system. Data QC is necessary to detect problems that are not so obvious or problems of an intermittent nature.

3.2. DATA REVIEW USING CANNED REPORTS

Following the downloading of a WIM system's daily data file (or files) to the Office Data Analyst's Office Computer, a data QC check is performed to determine if the data is suitable for its intended use.

3.2.1. Class and Speed Reports

It is recommended that the first check be made using daily class and speed reports summarizing the binned raw data. The purpose of this check is to take a quick look at each day's data to identify:

• Any missing vehicles for hour(s) in:
  • All lanes
  • One lane only
• Any atypical class count distributions
• Any atypical speed patterns

Figure 24 displays two reports with daily vehicle counts by hour for Lane Numbers SB1 and SB2. For this site, Lane SB1 is the outside lane, or "driving" lane, which normally carries most of the traffic. In the first report, it is obvious that the counts decrease significantly for Lane SB1 starting sometime after Hour 7 and ending sometime prior to Hour 16. However, a look at the counts for this time frame for the adjacent Lane SB2 (inside lane, or "passing" lane) indicates that the counts significantly increase. The total counts for both lanes are normal. This example represents a typical lane closure situation and the system is counting vehicles just fine. In the second report, both lanes are exhibiting a large drop in counts starting sometime after Hour 18 and ending sometime prior to Hour 21. This indicates that, for some reason, the system was not counting during this period or that some major event caused the closure of both lanes.

Figure 25 displays a report for a system that covers all four lanes (two lanes in each direction) of the roadway. This is an obvious case of either a temporary loss of power or the system simply malfunctioning for several hours (Hour 9 through Hour 14).

Figure 24. Reports. Missing hourly data for lane or lanes.

Figure 25. Report. Missing data all lanes.

Figure 26 displays a portion of a daily report with hourly counts by classification for the system's Lane 2. Starting during Hour 12 - 13 there was a large increase in counts for Class 1 and unclassified vehicles (Class 15, for this particular system). Also, a significant decrease in counts for the "good" classes is evident (although this lane has very few large trucks).

Figure 27 displays a portion of a daily report with speed range counts by hour for the same system, day, and lane as the Classification by Hour report displayed in Figure 26. At the same time that there were significant changes in the classifications, there were significant changes in the speeds as well. Also, Figure 28 displays that a vast majority of the invalid speeds are attributable to Class 1s and Class 15s (unclassifieds).

In that this site is located in an urban area with commute traffic, some of the low speeds may very well be legitimate. These three reports are from a system for which loop or loop-processing problems will typically result in Class 1 and/or Class 15 vehicles and unrealistic speeds. Although consideration must always be given to the possibility that a system's erroneous data may be attributable to congestion, an accident, or work on the roadway causing stop and go traffic conditions, the fact that the erroneous data continued for the entire afternoon suggests that for this example the system simply is not processing properly for Lane 2. As an additional check, Figure 29 displays a report comparing class and speed data for Lane 2 with that of adjacent Lane 1. Although Lane 1 does appear to have some erroneous data (probably due to the traffic conditions), its reasonable class and speed distributions make it evident that the Lane 2 problems are not due to major traffic issues.

Figure 26. Report. Erroneous classification for lane

Figure 27. Report. Erroneous speeds for lane.

Figure 28. Report. Speed by class for lane.

Figure 29. Report. Class and speed distributions, Lane 1 versus Lane 2.

Figure 30 displays a Speed by Hour report for Lane #1 for a WIM site that routinely experiences traffic congestion. For such a site, an increase in system errors and/or questionable classification counts should prompt the analyst to review the traffic speed distributions for the period of time in question. In analyzing the speed pattern and traffic volumes it is apparent that this site actually did experience very slow speeds for a two-hour period (probably stop and go). In this case, congestion appears to be the cause of invalid data, and not improper system operation.

For sites that experience routine traffic congestion, the onsite testing following initial installation and start-up should have confirmed whether or not the system met functional requirements in regard to its ability to properly generate data when traffic is travelling at the minimum speed of the required speed range. For example, if the specifications require that the system must function properly when traffic is travelling within a range of 5 mi/h to 100 mi/h, and onsite observation confirmed that errors start occurring only when vehicles actually stop when over the sensors, the system was functioning correctly. If, on the other hand, errors started occurring when vehicles were moving in excess of 5 mi/h, the system was not functioning correctly and the system should not have been accepted. If this type of testing was not performed prior to system acceptance, it should be performed as soon as the Office Data Analyst identifies low speeds as the potential cause of invalid data. Such onsite observations of the effect of low speed traffic on the system's data output should be documented such that the analyst will be able to make a judgment as to whether invalid data is due to system error or traffic conditions.

It is important that the analyst develop rules for each WIM site in regard to what levels of routine data errors caused by traffic operating characteristics may be expected without raising a flag that a system might be malfunctioning. A site located on a wide-open rural interstate freeway should experience very few routine data errors due to traffic operating characteristics whereas a site located on an urban roadway might experience a relatively high level of routine data errors which are caused by traffic, not system malfunction.

Figure 31 also displays a portion of a daily report displaying hourly counts by classification for a system's Lane #1. However, this system has the capability to identify specific types of system errors and include such error counts in a Classification bin (Class 14, for this particular system). For Hours 7 through 10 there was an increase in counts of system errors and unclassified vehicles (Class 15, for this particular system) and an apparent decrease of counts for the other vehicle classes.

Figure 32 displays a portion of another daily report for the system, date, and lane displayed in Figure 31. This report makes it evident that between Hours 7 and 10 there was an increase in loop errors/warnings ("Dwn Only"), as well as an increase in both unequal left sensor versus right sensor axle detections ("Uneq Det"), and no axle detections ("Zero Axl"). Although these system errors would not appear to be significant, they indicate either erratic traffic patterns or that the system was having some problems during this period of time. This system should be carefully monitored to determine if this problem was an isolated event or if it is occurring (or worsening) on a regular basis.

Figure 30. Report. Traffic congestion; legitimate low speeds.

Figure 31. Report. Change in class count pattern and increase in system errors for lane.

Figure 32. Report. System error identification.

In monitoring the distribution of vehicle classification counts, certain anomalies are best checked by "drilling down" to individual vehicle records by means of a process that will be covered in detail in Section 4. A few examples follow:

• Too many Class 13s and/or Class 15s caused by:
  • Improper loop delay setting, which results in two or more vehicles being combined into a single vehicle when traffic is dense.
  • Malfunctioning weigh sensor or improper sensor sensitivity setting, which results in a system adding axles ("ghost" axles) to vehicles.
• Too many Class 8s in relation to Class 9s caused by a system dropping one or more axles from some Class 9s.
• Too many Class 6s in relation to Class 9s caused by improper loop delay setting, which results in some Class 9s' tractor and trailer being split into two individual vehicles.

Note that a "drill down" to individual records can only be performed on vehicles meeting the user's criteria for a system's storing data as individual vehicle records (as opposed to a vehicle being only a "count" in various bins). Identification of erroneous data via review of reports generated from binned data is the first step in determining whether or not a system is, in general, functioning correctly and whether or not each day's data is suitable for its intended use.

The review of reports generated from individual vehicle records, as covered by the procedures that follow, provides more insight as to whether or not a drill down to certain individual vehicle records in order to determine the cause(s) of erroneous data is feasible. Subject to a system's data storage capacity, it may be of benefit to program the system to capture all vehicles to individual vehicle records for a day, or even a partial day, so that more comprehensive analyses can be performed on erroneous and/or questionable data.

3.2.2. Individual Vehicle Record Summary Reports

The next step in the QC process is a check of reports that summarize data contained in the individual vehicle records. Typically, a system is programmed to capture trucks, either by classification or by steer axle weight threshold, to individual vehicle records. The primary purpose of this check is to:

• Identify classification problems caused by:
  • Improper classification algorithms
  • Improper loop settings
  • Improper weigh sensor threshold setting
• Identify inaccurate weights caused by:
  • A malfunctioning weigh sensor
    • On-going vs. intermittent
  • Improper weigh sensor threshold setting
• Identify obvious calibration problems.

3.2.2.1. Identification of Classification Problems

Although some of these classification checks may appear to duplicate checks made on the binned data, they lead the way to a drill down process to analyze individual vehicle records in order to determine the cause of erroneous and/or questionable data.

Figure 33 displays a report that summarizes data from individual vehicle records for one lane of a system. This system is programmed to capture any vehicle with a steer axle weight of 3,500 pounds or greater, regardless of class, as a stored vehicle record. However, this report includes only truck classes (4 through 14) and unclassified vehicles (Class 15 for this system). A review of this type of report provides the analyst with a good overview of whether or not the system is functioning properly, and if not, what to look for in a drill down to individual vehicle records for further analyses.

Classification distributions and the number of unclassified vehicles can vary significantly from site to site and the analyst must be knowledgeable as to what type of pattern is typical for each site. The report displayed in Figure 33 is for a site in Michigan that does experience a relatively high volume of Class 13 vehicles. Although for most states a seven percent Class 13 count would indicate a problem, the summary data included in this particular report does not suggest any significant problems with the system. However, if this type of report did indicate a classification problem, the analyst might want to take a quick look at a few individual records generated by the Office Computer application software before going to the effort of importing data into a spreadsheet or database program for extensive analyses (as will be discussed later).

Figure 33. Report. Individual vehicle record class and weight summary data for one lane.

Figure 34 displays three examples of unclassified vehicles (Class 15 for this system). The first record is actually a Class 9 vehicle that was not properly classified due to its short Axle 2-3 spacing. The average drive tandem spacing for the Class 9's predominant Type 3S2 vehicle is 4.3 feet. From this record, it cannot be determined if any of the items below apply:

• This was an unordinary Class 9 with very small drive tandem wheels.
• The system did not properly process the Axle 2-3 spacing.
• All of the spacings are too short because the system is not properly processing the axle spacings.

It is noted that the "Speed" is reasonable, as is the "Veh.Length" (overall vehicle length). For systems that have been calibrated for overall vehicle length, if a vehicle record suggests that the system has elongated axle spacings or has added one or more trailing "ghost" axles, a comparison of the overall wheelbase (sum of all axle spacings) with the overall vehicle length is in order. With very rare exceptions, the overall length should be greater than the overall wheelbase.

The second record's data indicates that the system properly processed the vehicle's data elements. The system's classification algorithm should be checked to see if one of the items below applies:

• A three-axle vehicle with an Axle 1-2 spacing of 24.9 is not accounted for.
• The axle spacings are covered but the subject vehicle's gross weight is not accounted for in conjunction with the axle spacings.

The third record includes a "ghost" axle (Axle No. 3). This could be caused by either a malfunctioning weigh sensor, or an improper weigh sensor threshold setting.

Figure 34. Screenshots. Examples of vehicles not classified by the system.

Figure 35 displays two vehicle records which would appear to be legitimate Class 13s based upon the vehicles' data elements. Figure 36 displays a vehicle labeled as Class 13 due to its axle spacings and gross weight meeting the classification algorithm's parameters for Class 13. However, it is evident that this record contains "ghost" axles.

If a system generates a significant number of vehicle records that contain "ghost" axles, and a diagnostic check indicates that the signals from the weigh sensors look ok, try adjusting the sensors' threshold settings and observe the effect on the sensors' weight reading outputs. These adjustments must be made with care such that the system does not start to drop axles from its vehicle data outputs. One check for this is a before and after comparison of the Class 9 versus Class 8 ratio. If the Class 8 counts increase and the Class 9 counts decrease, it is a good indicator that the system is dropping axles for some of the Class 9s.

Figure 35. Screen shots. Legitimate Class 13 vehicles.

Figure 36. Screen shot. Vehicle misclassified as Class 13 due to "ghost" axles.

Figure 37 displays two vehicle records in succession, the first a Class 6 and the second a Class 5. Note that these two records are in the same lane at the same time (at least to the nearest second). It is also noted that the second vehicle has a recorded speed of 144.3 mi/h, which is another indicator that the WIM record is not valid. These two records are actually for a single combination vehicle, probably a Type 32 truck-trailer (Class 9) with a long tow bar (something similar to the photo in Figure 38). Since the loops did not pick up the tow bar and "timed out" before detecting the trailer, the system treated this combination vehicle as two individual vehicles.

Figure 39 displays a Class 9 logging truck. This vehicle is comprised of a three-axle tractor and a tandem trailer connected to the tractor by only the logs and a tubular steel connector. This is another configuration that can result in a system treating the combination vehicle as two individual vehicles. However, in this case, the second record would have an Axle 1-2 spacing of approximately 4.3 feet and, due to the tandem's being too heavy for a Class 1 vehicle under most class algorithms, would probably have been labeled as an "Unclassified" by the system.

Figure 37. Screen shot. Two records for one combination vehicle.

Figure 38. Photo. Class 9 Type 32 with long towbar.

Figure 39. Photo. Class 9 logging truck.

To prevent a system's loops from dropping out and creating two individual records for certain combination vehicles, the typical fix is to increase the system's loop time-out setting. However, for a site that at times experiences heavy traffic, an increase in the loop time-out setting may result in a system combining two or more tailgating vehicles into a single record. For this type of site the adjustment of the loop time-out setting may be a trial and error process to determine what setting produces the fewest errors. Consideration should also be given to the intended use of the data. If the priority is to collect the most accurate truck size and weight data as possible, it may not be deemed important if some tailgating autos are not counted and classified properly.

Any system is going to label some "real" vehicles as unclassified and misclassify some vehicles as displayed in the above examples. This is particularly the case when vehicles do not pass through the site within the lane lines or at normal speeds. A few random misclassified vehicles are not normally cause for concern. However, if a system's percentage of unclassified or misclassified vehicles starts to increase in the absence of verification that traffic characteristics have changed, a more in-depth analysis of vehicle records should be performed.

3.2.2.2. Identification of Weight Data Problems

Reports generated by a WIM vendor's application software should also include summary information on the weight data contained in the individual vehicle records. The report shown in Figure 33 displays information on the number of vehicles having "invalid measurements" (as per criteria programmed by the user) as well as information on the number of vehicles flagged as being in violation of weight limits, and a breakdown of the types of weight violations. This particular system conforms to LTPP's "model specification" (refer to Appendix A), which states:

An "invalid measurement" code shall be assigned to any vehicle ... when:

• The left and right wheel weights of any axle have a difference of 40 percent or more; and
• Either of the wheel weights of such axle exceeds 2.0 kip. Both the 40 percent and 2 kip values shall be programmable by the operator.

Regardless of a system's method(s) for flagging potentially erroneous weights, any system is going to generate some weights that are not valid estimates of static weights. As with erroneous classification, the number of erroneous weights can vary significantly among WIM sites depending upon truck operating characteristics, pavement conditions, type of equipment, etc. Based upon documentation gathered during onsite testing and observation, as well as initial analyses of vehicles being flagged as having potentially erroneous weights, the analyst should develop rules for each WIM site in regard to what levels of routine weighing errors caused by truck operating characteristics may be expected without raising a flag that a system might be malfunctioning.

Figure 40 displays a report that provides weight summary information from individual vehicle records for each of a system's three WIM lanes. For this system, a warning flag is applied to a vehicle's record when an "invalid measurement" (as discussed above) is detected, as well as other detections by the system (such as unequal detection counts by the sensors of left versus right wheel hits) that the vehicle's axle weights and GVW might be erroneous. Although the system's assignment of warning flags for 13 percent of the trucks in Lane 1 is certainly not indicative that a weigh sensor is not working, it is a relatively high percentage and should prompt a more detailed analysis to determine which weigh sensor is causing the problem. Upon such determination, real-time checks of the system's settings for the sensor can be made, and depending upon the particular features of the system, diagnostics on the sensor can be performed. If all real-time checks of the sensor do not indicate a problem, more extensive analyses should be performed to try to determine a pattern of intermittent malfunction. This system provides detailed reporting information on system errors and warnings, so the next step is to generate a report on the errors and warnings.

Figure 40. Report. Class distribution, weight violation counts, and warning counts by lane.

Figure 41 displays an abbreviated report listing counts of vehicles having system errors or warning flags by hour of day for the system's Lane EB4. This report makes it evident that the relatively high percentage of warnings displayed in the Figure 40 report is due to "Wt Dif" flags, which indicates that these vehicles met the criteria for "invalid measurement" as discussed previously. It is also noted that this problem is occurring on an intermittent basis. During each of the hours 2 to 3, 10 to 11, and 23 to 24, over 26 percent of the vehicles were flagged. It would appear that the problem occurs to a much lesser extent during the afternoon hours, rather than late night and morning hours. Any number of conditions, including the effects of temperature or moisture on conductor connections, can cause intermittent erroneous outputs by a weigh sensor, as shown in this report.

Figure 41. Report. Error and warning vehicles by hour for lane.

For sites that experience strong crosswinds and also have a relatively high percentage of combination vehicles with empty or very light trailers, a review of some of the vehicle records with "Weight Difference" warning flags might reveal that a high percentage of these records look similar to the display in Figure 42. This vehicle, traveling in a bidirectional site's eastbound lane, is an empty 2S12 Class 11 with very little weight on the trailer wheels and the trailers' lighter wheel weights are all on the left side. If the analyst can verify that the site did experience windy conditions for the time frames that the "Weight Difference" warning flags were higher than normal and that the winds were in a direction (from the north) that would hit the trailers of the eastbound vehicles on their left sides, the odds are very good that the left weigh sensor is functioning properly. Likewise, if the right weights of the empty trailers in the site's westbound lanes have lower readings, it is very likely that wind is causing the warning flags.

Figure 42. Screen shot. Vehicle with "light" wheel weights on left side.

For the example vehicle record displayed in Figure 42, the trailers' left and right wheel weight differences are insignificant from both axle weight and gross weight perspectives. If vehicles flagged by a system as having potentially erroneous weights due to the left versus right axle weight imbalance percentage are automatically discarded from weight reporting by the analyst for a site that routinely experiences crosswinds, many legitimately weighed empty vehicles may be discarded. This might drastically skew data utilized for both weight violation and loading analyses purposes. It is strongly recommended that for a system including features allowing the analyst to program parameters for assignment of left versus right imbalance flags that the system be programmed not to flag vehicles that are obviously empty and have minor left versus right weight imbalances for the trailer axles. For the example displayed in Figure 42, increasing the minimum wheel weight threshold to 3.0 k would result in this vehicle not being flagged.

For systems utilizing some type of "off-scale" sensors, which detect and flag any vehicle with one or more wheels not fully hitting a weigh sensor, there is no guesswork. If a wheel hits an off-scale sensor, the wheel's full weight is not being reported by the system.

For sites that do not have extremely smooth pavement profiles, the pavement may cause enough bouncing of truck wheels (particularly those of empties) to cause a significant left versus right wheel weight imbalance. If it is not feasible to fix the pavement smoothness problem, the analyst will need to determine what level of potential weight error flags is normal for the site and whether or not the system should be re-programmed to ignore imbalances for the lighter axles (if the system has this feature). This may also be the case where a weigh sensor is not perfectly even with the adjacent pavement, due to either a poor installation or post-installation rutting in the pavement.

Also, some sites experience occasional trucks that travel with their right wheels very close to, or even on, the shoulder stripe of the outside lane. Unless the weigh sensors at such a site extend to the right of the shoulder stripe, the system may report only partial weights for the right wheels of these trucks. Although this condition is simple to verify by onsite observation or by use of off-scale sensors, to determine by data analyses alone requires extensive effort.

A system's reporting of the types and/or times of error and warning flags is very beneficial to the analyst in isolating the cause and extent of erroneous weight problems. However, intermittent malfunction problems can be very difficult to diagnose, and the analyst may have to make extensive detailed analyses of individual vehicle records. This is best performed by importing the vehicle records into a spreadsheet or database program, as will be discussed in SECTION 4.

In the absence of adjustments in a system's calibration factors or a change in a site's truck operating characteristics, a significant increase or decrease in a system's weight violations suggests a problem with weight outputs beyond "fine tuning" of calibration factors. Weight violation data contained in reports such as those displayed in Figure 33 and Figure 40 should be monitored by the analyst for significant changes from the norm.

Figure 43 displays a report listing gross weight distributions for each truck classification for the system's Lane 4. If the WIM vendor's application software or the agency's software provides for generation of a daily report displaying gross vehicle weight averages and/or distributions, it would be a good idea for the analyst to also monitor these for any significant changes. The monitoring of the 3S2 steer axle average weights for any significant increase or decrease is also a good check if the application software provides for such reporting.

It may be difficult to determine if a change in weight outputs during cold weather is due simply to a seasonal variability in truck operating characteristics, or if cold temperatures are having an effect on either the weigh sensors themselves or a system's electronics. Although long-term monitoring, as will be discussed in SECTION 5, may provide an answer, performing an onsite validation with test trucks during cold weather would be of great benefit. For bending plate systems, consideration should always be given to the possibility of the scale pits being filled with ice.

If it is apparent that a weigh sensor is generating erroneous weights (or no weights) and the problem cannot be fixed from the office, it may be possible to access the system and, via the system software, remove the problem sensor and double the good sensor's output as a temporary fix until an onsite fix can be performed.

Figure 43. Report. Gross weight distribution for each truck class for lane.

3.2.2.2.1. Recap of Erroneous Weight Output Checks and Analyses

A system's generating erroneous weight outputs for a particular lane may be caused by:

• A malfunctioning weigh sensor.
• An improper system setting for a weigh sensor.
• An obviously erroneous calibration factor or factors.
• Trucks not traveling within lane lines.
• Strong crosswinds.
• Effects of very cold temperatures on weigh sensors or electronics.
• For bending plates, a scale pit filled with ice.

To identify the cause, extent, and action to be taken the analyst should use a "drill down" process. By reviewing canned reports the analyst can typically determine that the weights for a particular lane either have changed from the norm or are obviously erroneous, and whether or not the problem is ongoing or intermittent. Depending upon the extent of the erroneous weight outputs, the analyst may need to review only a sampling of individual vehicle records generated by the vendor's application software to identify the cause. It is very beneficial to understand and utilize any error and/or warning flags applied to the vehicle records by a particular system. If the cause of a problem cannot be identified by a quick review of a few vehicle records, it may be necessary to perform extensive analyses of individual vehicle records as will be discussed in SECTION 4.

As a summary, to check for erroneous weight outputs, the analyst should:

1. Determine which weigh sensor is generating erroneous weights by checking for:
   • "0" outputs.
   • Partial weight outputs.
   • Weight outputs that have significantly increased.
   • Erratic weight outputs.
2. Determine if a sensor is generating erroneous weights consistently or intermittently.
   • If consistent:
     • Check sensor's calibration factor settings.
     • Remotely access system and perform any sensor diagnostics available by the system.
   • If intermittent, attempt to determine if there is any type of pattern that provides a clue to the cause, such as:
     • Time of day.
       • Temperature or moisture.
     • Heavy versus light traffic.
     • Ongoing roadwork in the vicinity of the site.
     • Crosswinds.

3.3. AUTOMATED VALIDATION PROGRAMS

Several agencies validate WIM data utilizing proprietary software programs, which flag any vehicle in the individual vehicle records that does not conform to user defined rules and generate summary reports on flagged vehicles.

The Travel Monitoring Analysis System (TMAS) is an example of an automated validation program. TMAS is currently used to submit monthly traffic volume data to FHWA and will be used to submit vehicle classification and truck weight data to FHWA as well, replacing the Vehicle Travel Information System (VTRIS). Figure 44 presents a summary of the TMAS quality control checks for WIM data. It is noted that the TMAS checks are performed utilizing TMG formatted data files which do not contain all WIM data elements (such as a warning or system error code) whereas some automated validation programs perform checks utilizing the "raw" data files.

Figure 44. List. Summary of FHWA TMAS QC Checks.

Appendix B lists a multitude of possible validation rules that were developed under the Transportation Pooled-Fund Study SPR-2 (182), titled Traffic Data Edit Procedures Pooled Fund Study, Traffic Data Quality "TDQ". Additional information on this study is available online at http://www.fhwa.dot.gov/policy/ohpi/tdep.htm.

3.4. DATA QC - FOLLOW-UP PROCEDURES

If routine QC checks suggest a problem with a system's operation, the analyst should remotely access the system and perform a check of the system's setup parameters and the settings for any component that might be causing the problem. If the setup parameters and component settings appear to be correct, any diagnostics of the components provided for by the system should be performed. The data analyst may need technical assistance in performing and analyzing certain component diagnostics. It may also be beneficial to perform extensive data analyses, as discussed in SECTION 4. In this section it is discussed how to determine which component is malfunctioning, and if the problem is intermittent, at what time of day or under what conditions the malfunction occurs.

It is extremely important to determine whether sensor and/or processing problems are caused by system malfunction, by improper system settings, by traffic conditions, or by environmental conditions!

3.4.1. Real-Time System Check of Parameters and Settings

The purpose of this check is to utilize the remotely accessible features of a system to check, and if necessary, modify parameters, settings, values, etc. affecting system operation and data output. Such modifications made from the office can often eliminate various data problems without the need to make a visit to a site. Checks may include (but certainly not limited to):

• System/site setup configurations.
• Time and date.
• Parameters for data file collection, vehicle record capture, etc.
• Parameters for assigning flags for potentially erroneous weights, warnings, system errors, etc.
• Parameters for assigning weight violation codes.
• Classification algorithm.
• Loop time out settings.
• Weigh sensor thresholds (including "zero").
• Calibration factors for weights, speed (and thereby axle spacings), and overall vehicle length.

It is critical that upon acceptance of a WIM system from the contractor or vendor all system parameters, settings, values, etc. be documented and that any subsequent adjustments be documented and maintained as well.

It is far beyond the scope of this manual to go into detail on all of the various WIM system features available by the various system manufacturers. Several examples are displayed, but it is the responsibility of the analyst (perhaps with some dependency on available technical support) to become familiar with available features of any particular system.

Figure 45 displays an example of a record of the various parameters and values for Lane 4 of a particular system that is utilizing Quartz Piezo weigh sensors. The information on the lane's sensor configuration should not change unless modifications are made to the layouts of the site's lanes and/or sensors.

• The "Axle Sensors" parameters provide the system with each weigh sensor's input information and the distances from the leading edge of the lead loop to each of the weigh sensors.
• The "Loop" parameters provide similar type information for the loops. The loop "Width (cm)" values are used by the system to generate each vehicle's overall length, and these values are "fine tuned" by analysis of calibration or validation test truck data.
• The "Processing" parameters include:
  • A "MaxTimeout" value, which is the time allowed (in milliseconds (ms)) between a vehicle's triggering the lead loop and when the vehicle has been considered to have completed passage through the system (thus completing the vehicle's record).
  • User defined values for flagging vehicles with left versus right axle weight imbalances.
  • The distance between the leading and trailing weigh sensors ("Axl Sep"), which is used by the system to generate each vehicle's speed.
  • A value (in percent) for adjusting steer axle calibration factors ("Dynamic Comp")

The values for the "Axl Sep" and the "Dynamic Comp" are typically fine-tuned based upon analysis of calibration or validation test truck data.

Figure 45. Screen shot. Example of a record of a system's setup parameters for one lane.

Figure 46 displays a record of the same system's calibration factors for its Lane 4. It is noted that this system provides for calibration factors for five speed points.

Figure 46. Screen shot. Example of a record of a system's weight calibration factors for one lane.

Figure 47 displays a remotely accessible onsite menu page from another system type that also shows various parameters for the site, system sensor channel inputs, and the current value for "Loop delay constant" (which is the loop "timeout" or "drop out" previously discussed in this manual).

Figure 47. Screen shot. Example of a system's sensor configuration and loop delay constant for one lane.

It is important that the analyst have available all system setup parameter records. It is also important that the analyst be made aware of any changes in a system's values and/or factors related to calibration, and that the analyst record and maintain such values and factors for reference.

3.4.2. Remote Real-Time Tests and Diagnostics of System Component Operation

The purpose of this check is to utilize the remotely accessible features of a system to check signal outputs and/or other operational aspects of individual components of a system.

Again, it is far beyond the scope of this manual to go into detail on all of the WIM system features available by the various system manufacturers. Several examples will be displayed, but it is the responsibility of the analyst (perhaps with some dependency on available technical support) to become familiar with the features of any particular system. For certain systems, very detailed analyses can be performed on a sensor's raw signal output, but obtaining and analyzing such signal output is typically best left to engineers or technicians well versed in a system's operation.

Figure 48 displays a remote accessible onsite menu page from a system as well as three of the tests that can be accessed from the menu.

• Menu Item "5" displays how long each passing vehicle is sensed by the leading and trailing loops for each of the site's four lanes. The values are displayed in timer "ticks", each tick being the number of milliseconds set up in the system's setup menu (4.5 ms for this system). A value less than 20 usually indicates a misadjusted or faulty loop.
• Menu Item "6" displays the frequency, detuning, and output status for each of the four loop channels on the selected "DIP" loop board.
• Menu Item "C" displays the analog to digital conversion value for the bending plate assigned to the system's Channel 1 with no traffic crossing the sensor. For this system, this value should be approximately 800. Although the "Measured value" will briefly increase when a vehicle crosses the weighpad, and the "max. value" will also increase; the "min. value" should not decrease. An extreme reading, such as "0" or "4096", typically indicates failure of either the bending plate or its amplifier board.

Figure 48. Screen shots. Example of a system's menu screen for selecting system tests ("System test") and three examples of the tests.

Figure 49 displays Lane SB#2 real time vehicles in another system's "Diagnostics" mode. For each vehicle, the lead and trail loop durations, as well as the axle count detections and their durations for each of the two bending plate weigh sensors are displayed. Observing the real time traffic for several minutes per lane in this mode provides a good idea if the loops and weigh sensors are functioning correctly.

Figure 49. Screen shot. Example of a system's loop and weigh sensor duration diagnostics.

Figure 50 displays the same system's remotely accessible onsite menu page showing the current "Base Line Value" for the system's "WIM Sensor 1". This value should be 2048, plus or minus 100. For this system type, if a sensor's base line is out of range it will require an onsite visit to make adjustments to the sensor's interface card. An extreme value, such as 0 or 4096, typically indicates failure of the sensor or its interface card.

Figure 50. Screen shot. Example of system's menu page displaying a bending plate sensor's baseline value.

It is typical that at times the analyst may be able to attribute invalid data to traffic and/or environmental conditions instead of system malfunction. There may also be times that the analyst or technical support personnel can make corrections or adjustments to a system's setup parameters or various component settings remotely from the office to correct data problems. Unfortunately, at times it is necessary either to replace a failed system component or to make an adjustment to a hardware component that cannot be accomplished remotely via software or firmware. However, the more information the analyst can provide to the field technician as to which component is possibly causing data problems, the better prepared the field technician can be in having the necessary tools and equipment to fix the problem.

Contact

Mike Moravec
Office of Transportation Performance Management
202-366-3982
E-mail Mike