Modernizing Bridge Safety Inspection with Process Improvement & Mobile Computing 

This research was conducted to record and analyze the Virginia Department of Transportation (VDOT) bridge/structure inspection processes as an aid to modernizing these processes through the use of mobile personal computers (PC).  For purposes of this investigation mobile PC’s are Palm/Pocket PC’s and wearable computers.  The investigations were conducted using an informal conversational interview process coupled with direct observations to match perceived to actual processes.  The results of the interviews and observations were used to map inspector’s work flows.  Process maps were created and analyzed for operational bottlenecks and process improvement opportunities.  New process transformation maps were created and overlaid on current mappings to complete a transformation model.  These results and a comprehensive literature review were used to analyze the existing work processes.  Redundancies were observed in the inspection and reporting functions and bottlenecks were identified within the inspection management and inspection functions.  The research determined that the inspection process is readily transformable from one that relies on marking up paper reports in the field and then returning to the office for semi-manual reporting to one that is electronically assisted using mobile PC’s in the areas of field data capture, automated bridge inventory updates, and semi-automated report production.  From this analysis a series of strategies and recommendations were made.

Key Words: Mobile Computing, Bridge Inspections, Process Mapping, Pocket PC

Introduction 

Transportation infrastructure maintenance and improvements costs Virginia hundreds of millions of dollars annually.  Nationally this cost is in the billions.  Integral to maintaining Virginia’s highway infrastructure is timely inspections of the approximately 14,000 bridges.  To be eligible for federal highway funds the Federal Highway Administration (FHWA) mandates that each state establish a methodology to inspect and report bridge deterioration in compliance with the National Bridge Inspection Standards (NBIS).  The inspection results must be recorded on standard forms and submitted by the state for inclusion within the National Bridge Inventory (NBI) (NBIS 23, 2002).  State and federal laws and DOT policies mandates frequencies of inspections ranging from a monthly cycle to once every four years with the typical bridge inspection occurring every two years.  As a result there is considerable strain on a physical inspection process that performs between 7,000 – 10,000 inspections annually in Virginia alone. 

The primary objective of any bridge management system (BMS) is to make the best use of available funds in an overall bridge maintenance, rehabilitation and replacement (MR&R) program.  Each state’s DOT intends to meet this objective while maintaining a bridge infrastructure that is safe for public usage.  Without regular maintenance, the overall condition of a bridge deteriorates over time. Therefore, a BMS must utilize accurate and accessible inspection information to predict a bridge’s structural conditions.  As do many states, Virginia provides inspector training through a series of comprehensive standardized courses based on the FHWA’s “Bridge Inspector's Training Manual” and NBIS.  This commonality in training standardizes the inspection process by minimizing the variability in inspection observations and reports.  This process standardization lends itself ideally to the implementation and use of digitally assisted tools including mobile PC’s. 

Purpose and Scope 

The broad objective of this research was to investigate the inherent procedures and processes used in conducting bridge inspections and then map these processes to achievable methodologies that incorporate mobile computing tools for inspection modernization.  The scope of this work was limited to the work practices of field inspectors in field related processes of inspection management, bridge inspection, and conditions reporting; more specifically, this investigation involved how field inspections are managed, how data is collected, how the data is transcribed, reported, distributed, and archived, and how mobile PC’s can improve throughput and timeliness of bridge inspections.

Methodology 

The basic research was conducted using both informal conversation interviews and direct observation techniques.  Bridge inspectors from four separate districts were interviewed and then observed in their work environments.  Each inspector was individually interviewed and asked to describe the current processes they use to perform “routine” bridge inspections.  As the processes were verbalized they were recorded on “Post-It Notes” and arranged in a sequential order as defined by the inspector.  The “Post- It Note” work flows were captured and transferred into four process flow charts, one chart per District.  The completed charts were reviewed by each inspector to adjust and correct any errors. 

Each inspection team was then visited for the purpose of observing and documenting their actual work processes.  Once these processes were observed and validated, revised work flow charts were produced to reflect the actual field processes.  These revised work flow charts were then analyzed for process inefficiencies and/or bottlenecks that could be improved through mobile computing processes.  A literature review was conducted simultaneous with the work flow analysis to identify state of the art bridge/structure inspection practices.   

Current Bridge and Structure Inspection Processes 

Bridge Management System 

To comply with NBIS, many states created bridge management systems (BMS) similar to Virginia’s system.  To assist the states, in meeting these requirements and maintaining commonality in NBI reporting, the American Association of State Highway and Transportation Officials (AASHTO) and FHWA developed a software application known as Pontis, intended as a cradle to grave BMS.  By combining cost and condition data of 120 bridge elements, Pontis finds the recommended MR&R actions for each need.  VDOT uses only selected portions of Pontis to accomplish its bridge management tasks. 

Bridge Inspection Informational Components 

Bridge information in Virginia is combined and accessible within two distinct databases; Highway Traffic Records Information System (HTRIS), and Pontis Version 3.4.4.  These two database applications help the state meet its obligation for compliance with federal laws and NBIS.   Additionally, field inspectors prepare Structure Inspection Reports (SIR) composed of written commentary, deterioration quantities, graphical data, and photographs compiled from their observations.  Collectively, these three applications form the backbone of informational support and inspection data for Virginia’s BMS.  The “bridge management databases” themselves are diverse and have low interoperability.  Thus at the inspection level, the three main information interfaces that function independently but are used collectively to manage and record bridge/structure inspections are: 

1. HTRIS: an asset inventory database contained within a non-Windows environment that existed prior to the development of Pontis;
2. Pontis: a Windows-based BMS software application used selectively by VDOT for coded condition inputs;
3. SIR: a Windows-based word processing template used for recording commentary, photographs, and sketches.

Field Inspection Information Process Overview 

VDOT bridge inspection teams are composed of two people, a team leader and a team member, operating out of one of VDOT’s nine District offices.  Each team is assigned bridge and structure inspection responsibility within a particular geographical area (county or counties) and self manages their day-to-day inspection schedule within the required inspection cycles and training guidelines. 

A bridge/structure inspection is a multi-task process that eventuates through three distinct functions, 1) inspection management, 2) inspection and condition assessment, and 3) reporting.  Aspects of each these functions may occur during an inspector’s daily work routine.  The inspection management and reporting functions take place in the office while the inspection and condition assessment function occurs in the field.  The three distinct functional aspects of the inspection process are discussed below. 

Inspection Management 

The bridge inspection process initiates with the team leader or engineer extracting from the HTRIS database a list of bridges due for inspection during the next 90 to 180 days.  This inventory data is downloaded from HTRIS through a query that identifies all scheduled inspections located within the team’s geographical region during the queried period.  The inspection team manually sorts this inventory according to available equipment, consultant, month, county, and team leader.  The inspector will then mark up paper maps for each bridge location, pull the previous paper inspection reports in preparation for traveling to the bridge site.  While this process is convenient for the inspector in terms of initial data entry, one weakness is the inefficiency in gathering widely diffused data.  The ability to quickly extract precise data is one area of process transformation that can benefit from the integration of mobile PC’s into the inspection management function. 

Inspection and Condition Assessment 

Many bridges are located on rural roads with overgrown vegetation, low clearance, and spanning a creek or stream.  In addition to wearing hip waders, safety vest, and personal protection equipment the inspector must carry assorted equipment including a flashlight, a camera, basic measuring tools, and cleaning and inspection tools to assist in the inspection.  A clipboard, for taking notes on the previous inspection report, is carried throughout the inspection. 

The two-person team works in tandem with one person usually taking the notes and the other member verbally instructing the note taker on conditions being observed and/or measured.  The actual inspection and condition assessment occurs in a sequence of five basic tasks.  These five basic tasks that an inspection team will perform during a routine inspection are: 

1. confirm that the bridge matches inspection records;
2. conduct a systematic inspection, using visual and physical methods, including site photographs;
3. document on the previous written report, the currently observed conditions;
4. assign and confirm condition ratings and element condition quantities;
5. confirm and concur that the inspection is complete.

The inspection proceeds with the aid of the previous inspection report organized by standard predefined categories as identified in Table 1.  These categories are consistent with NBIS required inspection categories and are replicated within the SIR.  

Table 1 – Inspection categories

 Much of an inspection is done visually; however some aspects of the inspection include chipping, tapping, probing and measuring.  The superstructure, deck, substructure, and channel, all receive condition ratings on a 0-9 coded scale.  All new work completed since the last inspection is reported.  Photographs of the bridge are taken and new sketches drawn or existing sketches modified.  A channel profile must be conducted which includes checking for a change in topography and making sketches as necessary. All notations are done in red on the previous inspection report.  Before leaving the site all obvious inventory changes and MR&R recommendations are checked and concurred with by the inspection team. 

Reporting, Distribution and Archiving 

After completing an inspection marked-up reports are either filed temporary upon returning to the office, or the report is immediately prepared.  In reporting the HTRIS database is accessed and all pertinent information is entered and the database updated.  After updating and exiting HTRIS, Pontis is entered and its fields are updated.  Pontis updates are typically limited to quantities, conditions, and elements.  A Pontis paper summary sheet is printed and Pontis is exited.  The previous MS Word SIR file is entered and conditions are updated and/or modified to reflect the noted observations.  Other report edits such as inserting digital photographs and producing CAD drawings are also made at this time. 

After all modifications are performed, the SIR is saved with a new name.  A consolidated paper report (CR) is manually created by attaching the Pontis summary sheet, and any other reports that were necessary, to a print out of the SIR.  The CR is reviewed and signed off.  Upon signoff, five copies of the report are made and one copy is given to each of the following offices: District, Central, and Residency.  One copy is retained to be used as a field copy for the next inspection and the final copy is placed in the bridge’s master file. 

Bridge Data Fragmentation 

Although there are several redundancies in data storage, each software application, HTRIS, Pontis, and SIR contains only a portion of the entire bridge inspection data.  The SIR gives a descriptive commentary of conditions including sketches and photographs.  Pontis maintains coded condition ratings, quantities of element deterioration, and economic data.  HTRIS maintains among other items, location, geometric data, current condition states, structure age, traffic counts and special equipment indicator notations. 

The fragmentation involved in retrieving electronic inspection information is identified in Table 2.  This is typified by the fact that any text commentary, sketch, or photograph of current bridge conditions can only be retrieved through the SIR, with element conditions accessible only through Pontis and a bridge’s geometrical data can only be retrieved from HTRIS. 

Table 2 – Locations of Bridge Condition Data

 The effectiveness of data collection is constrained by the current data capture methods and then further constrained by the inspector having to process multiple documents, i.e., using existing reports to create draft reports, and then transcribing the draft reports into “new” HTRIS and Pontis data sets.  Also contained within the new reports are multimedia objects, particularly photographs and drawings that are either manually added to the new report or electronically inserted after being created, saved, and stored separately.  As a result there are between five to six generations of data compilation and report creation necessary to create a single final inspection report.  According to Leung (1996), document management poses a perplexing task to transportation agencies across the country.  Toward resolving this problem many DOTs have instituted efforts to develop mobile computing and automated data transference to assist in solving both data collection and document reporting problems.  

Information Automation in Bridge/Structure Inspection through Mobile Computing 

Mobile Computers 

There are three classes of mobile computers making their presence known in the inspection field; 1) handheld computers, 2) wearable computers, and 3) pen-based tablet computers.  These three classes of mobile computers are all battery powered, lightweight tools that can be carried, hard cased, holstered, or strapped to the inspector’s wrist in support of field data collection.  The tablets and wearable computers use the standard Windows OS, and are miniaturized to allow them to strap or hang on the body.  Navigation and data entry inputs, on all three classes of computers varies among tapping with a stylus, typing using a virtual or physical keyboard, hand written character recognition, and/or speech inputs.  

Personal Digital Assistants (PDA), Palm and PPC’s are miniature sized computers that combine the benefits of handheld pen-based input, long battery life and low cost with graphical user interface. Because these computers have high storage capacity and high quality writing recognition, they are well suited for form-based electronic entry of field data, much as current bridge inspections are done.  Nathwani’s experiments indicate that typically, several field inspections can be performed before the collected information needs to be uploaded to a desktop, laptop, or synchronized with an online server. Software is available to make these transfers, including Geographical Information System (GIS) and Geographical Positioning System (GPS) application interfaces (Nathwani, et al, 1995). 

Palm computers, PPC’s, and PDA’s, differ mainly in operating system, range of applications, and computing power.  Most PDA’s use a Palm OS and have low computing power and typically act as a contacts and appointment manager.  PPC’s are based on the Windows OS desktop metaphors (Windows CE/Mobile 2003) and consequently offer many of the same applications developed for desktop computers.  A typical PPC is delivered with Pocket Word, and Pocket Excel, and a digital image viewer. The standard SIR template was downloaded to a PPC and edited in the field using Pocket Word.  Palm OS have similar capabilities although conversion software is necessary to use MS Word and MS Excel. 

There are also several PPC database programs, including Visual CE that allow synchronization with server based databases that allow easy creation and development of data entry forms linked to database applications including MS Access and Oracle.  As a result, standardized data forms are easily replicated for PPC’s and data entry can be input in an electronic manner similar to manual bridge inspections. Because PPC’s have more memory than Palm’s and PDA’s, they can store more field inspections, on-site field sketches and even record signatures (Elzarka et al, 1999).  Since Elzarka’s research, both Palm and PPC’s are able to have digital cameras, large size memory cards, GPS devices, barcode and radio frequency identification tag (RFID) scanners, directly attached for improved data collection.  In addition to PDA’s and PPC’s, wearable computers offering hands-free and/or near hands-free technologies have been developed and explored in bridge inspection environments (Sunkpho and Garrett, et. al, 1998). 

Experimental Automated Bridge Data Collection Methods 

Several automated bridge inspection data collection systems have found application through limited field research.   One of the systems has been commercialized and another system from France is being adopted domestically. These applications include the Automated Data Collection (ADC) program and the Pontis Data File Creation (PDFC) program researched by Fanous et al  (1996);  the Automated Bridge Inspection System (ABIS) researched by Elzarka and Bell in conjunction with Clemson University and the South Carolina DOT (SCDOT) (Elzarka and Bell, 1997; Elzarka 1999); the Integrated Bridge Inspection Information System (IBIIS) developed in conjunction with Massachusetts Highway Department and with the Rhode Island DOT (RIDOT) (Nathwani and Shroff, 1995) and ScanPrint by the Advitam Group.  

Fanous et al (1996) working with the Iowa DOT developed two automated data collection methods for conducting bridge inspections in the field: the Automated Data Collection (ADC) program and the Pontis Data File Creation (PDFC) program. Both are data collection software applications written for handheld pen-based computers in support of the Pontis BMS.  This software was trial tested with the Iowa DOT and changes made to improve its focus as a field data collection tool and a translator to prepare field data for transfer into Pontis. 

The Integrated Bridge Inspection Information System (IBIIS) was developed in conjunction with the Massachusetts Highway Department and with the Rhode Island DOT (RIDOT), and converted by Trilon, Inc. to commercial application (Nathwani and Shroff, 1995).  Trilon, Inc. has refined and commercialized the product and now markets it for assistance in field data collection, and reporting within the Pontis BMS framework.  In 1995 Trilon, Inc. developed, “Inspection on Hand” (IOH), a commercial bridge inspection program.  Like ADC and PDFC, IOH is designed to support a Pontis BMS using a PPC.  IOH simplifies the data gathering process by guiding bridge inspectors through Pontis inspections with pop up menu screens (www.trilon.com/trilon, 2002). 

The French product ScanPrint, by Advitam Group, is intended as a BMS but does not incorporate an interface with Pontis, although its software does enables the user, through a tablet computer, to define asset inventory with the normal alphanumerical coding, assign geometrical data, input CAD drawings, provide element definitions, digital photographs, and uses “smart facets.”  This application is being distributed domestically through a Columbia, MD subsidiary and is being used by bridge inspection consultant, Parson Transportation Group for data collection and bridge management to support portions of the Michigan DOT BMS (Sawyer, 2002, www.advitam-group.com, 2002). 

A Japanese research team developed a prototype on-site inspection support system that offers several possibilities in alternative bridge inspections techniques. This system as developed by the researchers consists of a Radio Frequency Identification (RFID) tag system, a PPC connected to the Internet, a voice input/output system, and a digital camera.  A field inspector carries a PPC, a cellular phone, and a digital camera.  The PPC also has an RFID tag “reader-writer.”  The research team investigated cost, efficiency, availability, advantages and disadvantages of information access methods, and concluded that a “hybrid method,” combining a central server, the RFID tags (with up to 3MB of memory) at the site, and a PPC downloaded with certain data as the most suitable for an inspector’s mobile tool.  In this hybrid method, RFID tags contain basic data about the facility or member, such as the ID, main feature or specification, inspection procedures, latest measured data, latest inspection notes, etc. The PPC contains measurement data, digital photographs, digital sounds, information about inspection routes, etc. within its available storage limitations. The remote office server contains all the archived data, documents and drawing files not carried to the site in the PPC (Yabuki, et al, 2002).  

Inspection Process Transformation 

Understanding Inspection Functions 

Table 3 concisely outlines and identifies the basic inspection functions and their accompanying paper based manual actions paralleled with proposed digitally assisted actions using mobile PC’s.  As can be ascertained from the parallel views and previous discussions, standard paper based actions are readily transformable into automated and mobile PC assisted process. 

Table 3 – Inspection process management functions and associated actions

For process transformational purposes all three inspection functions are considered essential components of the whole inspection process and each must be addressed and integrated into the whole for process transformation to succeed.  The basic function of “inspection” is to provide asset information that can feed infrastructure management strategies of analysis, MR&R, and budgets.  The closer that process transformation reaches process integration, the less distinct the functional differences become.  This conclusion became evident and was observable in the process maps as they grew more concise and functions began to overlap as automated solutions were advanced.  See figure 1 for alternative inspection processes supported by mobile PC’s. 

 Proposed Inspection Management Alternative 

Inspection Management initiates by running a database query seeking inspection, scheduling, and other support data.  The results of this query are automatically downloaded to the mobile PC for transport into the field to assist in completing the inspection.  Inspection initiates in the field with the GPS equipped mobile PC verifying and mapping the previously downloaded bridge coordinates to the bridge’s exact geographical location.  The verification is stored internally for later uploading back into the master database.  Simultaneously with verification of the bridge’s location, the mobile PC activates the previously download data including, previous inspection reports, completed or scheduled maintenance activities, digital images, sketches, drawings, and other desired data. 

Proposed Inspection Function Alternative 

To support the Inspection function with mobile PC’s involves: 1) developing a tool that allows error free field identification of specific bridges (GPS, RFID, barcode), 2) enabling a systematic inspection process (electronically guided and edited field forms), 3) provides for a hands free operation (wearable computer), 4) can incorporate multimedia inputs (digital camera), and 5) has database interactivity (compatible input/output databases).   

Thus the proposed alternative to modernize bridge inspection data collection is to use a handheld or body worn computer with IOH, ScanPrint, or using a custom data collection application.  Drop down menus, “smart tags,” and speech recognition would be used for commands and assisted inputs.  Figure 2 shows two PPC screens that were created using Visual CE to successfully test a database customization that allows Mobile PC data input and then stores the data in records using NBIS/SIR fields.  The test application also allows freehand sketch capability and digital signatures.  In its final version any application should allow both new free-hand sketches and/or menu assisted on-screen sketching over agency created template sketches or over previously drawn sketches. 

 An attached digital camera is used to take standard view, and selected element photographs as prompted by the device.  The images are cataloged and stored on the mobile device within linked cells in pre-formatted data collection screens.  PPC camera image capture tests were done and inserted into the test PPC database.  Data not stored on the device, i.e., manuals, CAD files, etc. but needed because of unique circumstances could be wirelessly accessed from a support server and opened on the mobile device. 

Evident from the observations are the requirements for dexterity, agility, and the extensive use of an inspector’s hands to climb about, and manipulate various tools during the inspection.  Therefore in developing processes that encompass mobile computing tools, consideration must be given to a tool that minimizes using the inspector’s hands during both inspections and inputs.  The most desirous tool is one that assists or leads the inspector through a systematic inspection.  This can be done either through voice inputs or by smart tag/macro assisted inputs and allows for inclusion of multimedia objects including previous reports, digital photographs, drawings, sketches, and digital signatures and electronic links to the DOT database.  From the research it appears that Pontis Version 4.2, released in September 2003 may meet most if not all of these inclusion requirements (Pontis Version 4.2 Users Guide, 2003).  All aspects of data collection appear achievable using Palm/PPC’s and tablet computers. 

Upon returning to the office, the mobile PC is synchronized with the agency server and all data collections are uploaded into their appropriate master data fields.  Once data is synchronized within the proper data fields, automated report features are activated and pre-configured reports are prepared.  The system then changes the inspection status from pending to completed. 

Proposed Reporting Function Alternative 

Evident from the analysis is that portions of the inspection process are adhering to the rules and boundaries of a paper based system.  The absence of unified electronic inspection reports perpetuates an inefficient and cumbersome inspection cycle that begs for automation.  Inefficient reporting practices can be eliminated with the implementation of a process in which an inspector can retrieve previous reports on site through a mobile PC.  Once the report is accessed, multimedia data could be entered directly into the final report and uploaded from the field device to a server wirelessly through a synchronization process. This process would combine field data collection with report preparation and avoid separate data entry into the multiple programs. 

Pontis Version 4.2 appears to have the capabilities to compile all the data, condition elements and multimedia objects into a single electronic report and offers opportunity to be this common “gateway.”  In effect, all inspection data can be entered directly into Pontis Version 4.2 and then uploaded to HTRIS if desired.  The final document is electronically consolidated and can be printed for review by the inspector and engineer and then signed off or it can be viewed electronically and then signed off with digital signatures.  Archiving is handled electronically and distribution to users would be handled electronically through the use of “push/“pull” processes.  In both “push” and “pull” processes the original document remains archived on a central server.  A hard copy of the commentary, similar to the CR can be output in a paper format as necessary. 

Recommendations to Transform to a Mobile Computing Inspection Enterprise 

The proposed strategy to completely modernize VDOT bridge inspections is to eliminate paper processes in favor of using mobile PC’s for both data collection and automated reporting.  Reporting feeds directly into inspection management by simply running a schedule report and downloading it to the mobile PC.  This same modernization process is being pursued at varying levels by other DOTs, notably, Michigan, California, and Florida. 

The recommendations spanned from project startup to DOT acceptance.   This research determined that there are currently three viable mobile PC opportunities that can move the current inspection process into a mobile PC supported enterprise.  These three approaches are:  

1. Custom software development: develop and trial a customized application that creates a robust interactive database linkage between the master database and mobile devices.  
2. ScanPrint software: investigate and trial the use of “ScanPrint” as a wearable hardware/software solution;
3. IOH software: investigate and trial the use of “Inspection-on-Hand” and Pocket/Palm PC’s as a hardware/software solution that accomplishes the same objectives as a customized system.

 Before adopting any hardware/software product or solution, it was recommended that all three approaches be investigated to determine the most cost effective, user friendly and appropriate solution in support of VDOT’s mission.  Additionally the recommendations suggested that these three approaches must be coupled with an agreed upon prioritization of the objectives that mobile field inspections should achieve.  Once the above research is done and the applicable solutions are valued against the defined objectives, hardware/software solutions can be further evaluated, specifications can be prepared, and a pilot program to validate system capabilities can be done.  This effort can be followed by small scale prototype pre-adoption testing and finally prototype evaluations.  Once pre-adoption testing is completed a deployment strategy can be implemented. 

References 

Advitam Group. (2002). ScanPrint product guide. 2002. http://www.advitam-group.com. Accessed August 2002. 

Elzarka, H. and L. Bell. (1997, April) Development of pen-based computer field applications. Journal of Computing in Civil Engineering, pp. 140-143. 

Elzarka, H., L. Bell and R. Floyd. (1999 Nov.). Automated data acquisition for bridge inspection. Journal of Bridge Engineering. 

Fanous, F., L. Greimann, and A. Soni. (1996). Automated methods for collecting bridge inspection data in the Pontis format, 1996 Iowa Semisesquicentennial Transportation Conference. http://www.ctre.iastate.edu/pubs/semisesq/session5/fanous/. Accessed August 2002. 

Leung, A. (1996, March). Perfecting bridge inspecting. Civil Engineering, pp. 59-61.  

Nathwani, S., A. Shroff, G. Romack, and M. Rice. (1995). PDA-based field data collection for Pontis. International Bridge Conference, Pittsburgh, PA. 

Nathwani, S., and A. Shroff. (1995). Effective bridge maintenance using multimedia and mobile systems, Sixth International Conference on Structural Faults and Repairs, London, England. 

NBIS 23. (2002) National Bridge Inspection Standards, 23 CFR 650.3. 

Pontis Version 4.2. (2003). User’s Guide. 

Sawyer, T. (2002, March 4). Putting field notes in context. Engineering News-Record, http://www.enr.com.  Accessed March 2002. 

Sunkpho, J. and J. Garrett. (1998, October 19 – 20). MIA: A wearable computer for bridge inspectors. Second International Symposium on Wearable Computers, Pittsburgh, PA, http://www.computer.org/proceedings/iswc/9074/9074toc.htm. Accessed October 2002. 

Trilon, Inc. (2002).  http://www.trilon.com/trilon/. Accessed September 2002. 

Yabuki, N., K. Tomita, and Y. Shimada. (2002, June 12-14). An on-site inspection support system using radio frequency identification tags and personal digital assistants. International Council for Research and Innovation in Building and Construction, CIB w78 Conference 2002. Aarhus School of Architecture, Copenhagen, Denmark.