PDA-BASED FIELD DATA COLLECTION FOR PONTIS
INTERNATIONAL BRIDGE CONFERENCE, PITTSBURGH, PA
JUNE 1995
Sanjiv Nathwani, Trilon, Inc. (New Brunswick, NJ)
Avanti Shroff, Iffland Kavanagh Waterbury, PLLC (New York, NY)
George Romack, Federal Highway Administration (Washington, DC)
Mike Rice, Maryland State Highway Administration (Baltimore, MD)
INTRODUCTION:
The Maryland State Highway Administration (MD SHA) has just completed the evaluation of a hand-held, pen-based electronic field data collection device for use in bridge inspection as part of a demonstration project sponsored by the Federal Highway Administration (FHWA). One of the goals of the project was to examine the use of electronic field data collection tools in bridge management, and to determine their relevance as supporting technology for the Pontis Bridge Management System (BMS).
Currently, most bridge inspection programs that are converting to Pontis rely on pen and paper to collect bridge condition data. Typically, bridge inspectors are also expected to carry a manual into the field that provides bridge element descriptions and condition state language for Pontis-style inspections. This may be both cumbersome and time consuming. The handwritten rating data must be typed into the Pontis database, or an intermediate database that feeds Pontis, and the manuals are often damaged or lost during inspections. Additionally, inspectors often supplement rating data with handwritten comments to highlight specific conditions.
Some bridge inspection programs have started to use laptop computers in the field which allows for commentary to be entered directly in electronic format, and allows inspectors to type in the condition information to an intermediate database. This saves considerable time for office staff, but still places an additional burden on the inspector. Other inspection programs have experimented with DOS based hand-held, pen-based devices with some success.
A new class of computers called Personal Digital Assistants (PDAs) are potentially the best suited for structural field inspection. They combine the benefits of hand-held portability, pen-based input, a Graphical User Interface (GUI) with usable handwriting recognition, low cost and long battery life. In addition, a rich offering of software tools and hardware peripherals for these devices makes them even more attractive to the end-user.
This paper details the experience of the FHWA and MD SHA in association with their consultants in the testing of PDA based electronic field data collection for Pontis. It discusses the benefits observed and makes recommendations for full scale implementation of the technology for collecting bridge inspection information.
BACKGROUND:
The Intermodal Surface Transportation Efficiency Act (ISTEA) of 1991 set forth the requirements for the development of Bridge Management Systems (BMS) for all transportation agencies nationwide. The goal of a BMS is to improve the quality and speed of decision making regarding the priority allocation of limited funds to vast numbers of bridges requiring attention. A BMS provides essential information to help enhance safety and extend the service life of bridges.
The quality of bridge inspections, repair projects, and bridge management decisions is dependent on the quality of information collected in the field. It is important that Maryland and other states take advantage of existing technology and look for improved ways to collect, organize, store, and provide adequate access to this vital information. It was Maryland's belief that a PDA based field data collection system in combination with a multimedia bridge information system could accomplish all of these objectives and enhance the quality of a bridge inspection program. It was felt that if the BMS concept could be expanded to include the management of multimedia information and field data collection, it could live up to the task of providing a complete computing environment for informed bridge management.
EQUIPMENT AND SOFTWARE:
The following equipment and software was selected for use in the project:
• An industry-standard Personal Digital Assistant (PDA). This PDA was regarded as being a mature example of this class of technology, and one that was extensively supported by third party developers.
• Pontis data entry software prototype. This software allowed Pontis element condition rating data to be entered onto the PDA and communicated to a PC for transfer to the MD SHA bridge inspection database.
• PC DOS/Windows Notebook Computer (Laptop). This computer was used to run the MD SHA bridge inspection database and PDA communication software.
• PDA Connection Software. This software facilitated communication between the PDA and the Laptop.
PROCEDURES:
The PDA data entry software displays a form for entry of Pontis element condition rating data. All data entry would be done via handwriting recognition with the option to use an on-screen keyboard. The following goals were established for the prototype:
• Test the ability to enter and store information on bridge inspections such as bridge identification number, date of inspection, time of inspection, inspection team number, etc. Each inspection would be uniquely identified by a combination of the bridge identification number, date of inspection and time of inspection.
• Test the ability to associate pre-defined elements with specific bridges to create a bridge profile (see Figure 1). Thus, the software would automatically present the correct elements to be rated for the bridge inspection selected.
Figure I. Bridge Profile Screen
• Test the ability to enter and store bridge element condition rating data on the PDA (see Figure 2). The screen should be context sensitive in that only the number of condition states associated with each element would be displayed for entry, i.e. if the selected element had four condition states associated with it, only four fields would be displayed for condition rating data entry. The screen would also provide a mechanism to allow the inspector to arrive at a condition state rating by aggregating multiple entries into the entry fields.
Figure II. Bridge Element Condition Rating Screen
• Test the ability to enter and store condition comments associated with each inspection. The comments could be long enough to require several screens worth of text. Thus, the software must have the ability to display the text in a scrolling window for both comment entry and retrieval.
• Test the ability to enter and store the condition of the environment at the time of the inspection for each element. The four possible environmental options given in Pontis should be presented in a select list along with the entry fields for condition rating data for each element.
• Test context-sensitive help for all data entry fields. In the case of the elements, the help provided the short element description and the complete element description language (see Figure 3). In the case of the condition state entry fields, the help would provide the full condition state language from the Pontis manual (see Figure 4).
Figure III. Example of the Short Element Description and the Complete Element Description Language.
Figure IV. Example of the Full Condition State Language from the Pontis Manual.
• Test the ability to load bridge inspection comments from MD SHA's database on the Laptop to the PDA. This would allow inspectors to mark up existing commentary rather than recreate it.
• Test the ability to transfer data collected on the PDA to the MD SHA database on the laptop. The MD SHA database could then transfer the data to Pontis.
Six bridges were selected for the field test, each different in size, construction, condition and access. The goal was to use the PDA under as many different conditions as possible to test both the comfort level of the inspectors with the PDA and the performance of the data entry software.
It was decided that the inspections would be performed in two separate field trips. Each trip would cover three bridges and would last several days. The goal was to use recommendations from the first trip to improve testing procedures in the second trip. In addition, it would allow time for the data entry software to be modified to accommodate findings from the first trip. Inspections were to be performed by MD SHA personnel with the consultants assisting.
OBSERVATIONS:
Field inspections of the six bridges selected yielded the following observations on the performance of data entry software:
• Current MD SHA procedures for Pontis inspections would require inspection teams to carry a clipboard with paper entry forms, and the Pontis manual while inspecting a bridge. It was observed that having the on-line help would remove the need to have a paper manual, and could provide much easier and faster access to information such as condition state language than using a conventional manual.
• The ability to aggregate a total from multiple entries into a condition state entry field removed the need for 'margin math' on paper. The way large structures are inspected, an inspector must traverse the entire bridge either on foot or in an access vehicle, entering condition states of the various elements observed as he/she proceeds. For most elements, it is not possible for the inspector to enter a single number representing the condition state of the entire element, since a complete assessment of the element may require the traversal of the entire bridge, or large sections of it. Thus, inspectors often resort to keeping a running total in the 'margin' of the rating form as each subset of the element is observed. This error-prone process is eliminated by using the data entry software.
• The ability to enter comments to the data entry software eliminates the need for clipboards in the field altogether. Initially, no facility for entry of commentary was planned in the prototype modifications to the data entry software, since Pontis inspections do not require creation of any commentary on structural condition. However, it was felt that a real world bridge inspection would require inspectors to comment on emergency and special conditions, and if the proposed automation did not facilitate that need, it would be unable to replace paper forms and clipboards completely.
Initially, a simple blank screen that would allow the entry of handwritten text for new comments was planned. However, it was observed by the inspectors during preliminary testing that while the handwriting recognition on the PDA was near perfect for numeric data entry, it was less reliable for entry of text. It was felt that if the entry of comments could be restricted to updating the previous inspection's comments, it would reduce the amount of textual entry to a manageable level. Thus, the ability to load commentary from the MD SHA database on the laptop was implemented.
Double entry of information was eliminated. Current MD SHA procedures would require inspectors to use paper forms while performing the actual inspection, and to type in the information from the paper forms into the MD SHA database on the laptop after the inspection is complete. Using the PDA-based data entry software eliminated the need for typing in information to the MD SHA database, since the data transfer from the PDA to the Laptop was automated.
The overall commentary on the data entry software from the inspectors was that it was intuitive and easy to use. It was noted that due to the PDA environment, the graphical elements of the data entry software behaved differently than might have been expected in an application designed for a PC. However, the differences were easy to adjust to once they had been identified and noted.
The following observations were made on the performance of PDA:
• The PDA's form factor and low weight were considered a benefit. The inspectors observed that the PDA was easy to use by holding the device in one hand and using the stylus with the other. However, it was also observed that the small screen size resulted in somewhat crowded data entry screens. On balance though, the small size was considered a benefit. The holster provided for the PDA was convenient to wear on the belt and provided good protection for the device against abrasion and shock.
• The PDA environment was intuitive and easy to adapt to. The GUI was similar to ones available on PCs, and thus was easy to learn. Some difficulties were observed in using the stylus for writing, since the writing surface was much smoother than paper. However, the inspectors felt that they were able to compensate for the smooth surface effectively, and it did not present an ongoing problem.
• The PDA was much cheaper than conventional hand-held, pen-based computers. Devices used in the field are prone to damage and loss, thus the cost factor is a significant consideration.
• The PDA was insufficiently rugged for field use without additional gear. The PDA was not designed for field use, and thus did not have adequate protection against shock and abrasion. This was mitigated somewhat by the small size and low weight of the unit - it was less likely to be dropped accidentally. Several options have since become available that should provide adequate protection during field applications.
• The PDA was insufficiently resistant to water without add on protection. The concern was not so much for units dropped in water, as for units operated in heavy rain. As a test, one unit was wrapped in a clear plastic bag and given to an inspector for use. He found that whereas it was still easy to write and tap on the PDA, it was somewhat more difficult to read the screen. At least one product has since been found that would provide adequate water resistance for the PDA without diminishing the clarity of the screen.
• The PDA screen was hard to read in low light conditions without an additional light source. A clip on light was tested and found to be adequate until a more secure attachment could be made with the PDA. It was speculated that a small miner's lamp worn on the forehead might also be effective in this case.
• The handwriting recognition on the PDA was excellent for numeric entry and deficient for textual entry. It was observed that the recognition software was erratic in its recognition of handwritten words. The results varied based on the user and the vocabulary used. It was noted that as the inspectors adjusted their writing styles to meet the PDA's needs, the recognition improved, sometimes dramatically. In addition, as the PDA's dictionary was gradually filled with engineering terms, the recognition improved significantly. On the other hand, the inspectors found the on screen keyboard easy to use, and adequate for entering short sentences, or corrections to existing commentary.
• The holster was adequate to hold and protect the PDA when it was not in use, but inspectors were still concerned about dropping the unit accidentally while using it. It was noted that dropping the unit would become an even greater concern in cold weather conditions where dexterity may be impacted by the temperature. Similarly, the inspectors noted that the sudden movements of a bucket truck or a snooper increased the chances of a unit being dropped. A simple solution was offered by the inspectors - tether the unit to the wrist of the inspector using a nylon cord. The cord could be attached to the unit directly, or via the protective casing.
• The stylus that is used to write on the PDA was dropped several times by the inspectors. Usually, this was just a minor inconvenience. It was noted that if the stylus was dropped and could not be recovered, it would greatly hamper the inspection process. A tether was suggested to attach the stylus to the PDA.
• No temperature test was performed in the field, since the bridges were inspected in the autumn. However, the units were tested by putting them in a refrigeration unit for varying lengths of time. It was noted that the PDA was immediately usable after refrigeration, but that the screen response became sluggish. There is still some concern about the use of the units in extreme winter conditions. In discussion, some potential solutions were found; chemical based heat packs, or battery operated heating strips for gloves could be used in conjunction with the protective casing.
• The battery life on the PDAs was considered adequate. The units operated on 'AA' sized batteries for about one week, and could be used with optional rechargeable batteries.
• The PDAs data storage was sufficient for several weeks worth of inspection data. The storage for these units is provided by PCMCIA RAM cards available in 2 MB and 4 MB configurations. Extrapolating from the storage required for the six bridges inspected, a 2 MB card would be adequate to provide storage for at least several weeks of inspection data.
RECOMMENDATIONS:
On balance, the project found that PDAs, when paired with the appropriate data collection software, can be very powerful tools for performing Pontis inspections. The technology is maturing, but it is usable with good results today. Many of the deficiencies noted above are easily corrected by using other add on products.
PDAs are recommended for field use in the following configuration:
• One PDA per inspection team.
• At least one 2 MB RAM card for data storage for each PDA unit.
• Rechargeable batteries and a charger capable of being operated from the inspection vehicle's battery
• A holster for carrying the unit when it is not in use to protect it from shock and abrasion.
• A protective case to minimize damage to the unit from shock and abrasion while in use.
• A clear, water resistant cover or membrane that does not obscure the PDA screen.
• Chemical heat packs or battery operated heat strips to be used with the protective casing for extreme winter conditions.
• A miner's head lamp or similar lighting device to illuminate the PDA screen in low light conditions.
Following is a summary of recommended procedures for using PDAs for Pontis inspections:
• Provide each team with enough bridge data on their PDA unit's RAM card to last them for the duration they are typically in the field. If teams are required to be in the field for extensive periods, they may need to be outfitted with more RAM cards than recommended above.
• If the teams are outfitted with laptop computers for use in the field, provide them with software to transfer data from the PDA to the laptop computer after inspections. This will allow inspectors to transfer information periodically to the home office via modem. This may also be helpful in emergency situations.
• If teams are not outfitted with laptop computers, then have them download data to a designated PC at the office every time they return from a trip.
• For those organizations that will not convert to Pontis inspections only, it would be possible to develop a data collection application for NBIS, SI&A and safety based inspections.
• Global Positioning Systems (GPS). Several vendors are already producing this technology for PDAs.
• Geographic Information Systems (GIS). PDAs can be used in the field to perform many of the same GIS functions that are performed on workstations in the office.
In closing, it is important to note that the PDA technology is young, and as a result there is a wide variation in the maturity and robustness of the various units on the market. Some manufacturers have already pulled products from the market. Thus it is important to select the specific PDA carefully, with an eye to the product's maturity, stability, and support from third party vendors.
CONCLUSION:
The potential benefits from using PDA technology for Pontis inspections reaches beyond simply replacing paper information with electronic information. It is clear that the technology can provide vastly improved access and management of the inspection information. In turn, this enhances the quality and speed of inspections, with potential ramifications for response to emergency situations. Additionally, PDA based automation may provide a much easier transition to new inspection procedures for organizations that are in the process of adopting Pontis.
 |
 |
TRILON, Inc.
528 Winfield Avenue Upper Darby, PA 19082-2122 (215) 790-6265 voice (215) 790-6231 fax Info@Trilon.com http://www.Trilon.com |
|
|
IBIISŪ and the IBIIS logo are registered trademarks of Iffland Kavanagh Waterbury, PLLC and Trilon, Inc.
