UCII: On-Line Bridge Monitor

Monitor Software:

Data Acquisition Set-Up at HAM-126 (Software)

For the bridge monitoring system at HAM-126-0881, the following was implemented:

• A 10/100 Base-T Ethernet LAN board was installed in the PCI bus of the onsite computer,

• A Cisco 675 Router was connected to the Ethernet LAN board, which has recently been upgraded to a Lucent Cell-pipe, the analog modem, and the phone line.

• An account was generated with the ADSL service provider known as Zoomtown, a division of Cincinnati Bell, that routes the data stream to the Internet, and

• An account was generated with an Internet Service Provider (ISP), the University of Cincinnati, in this case, for data transmission over the Web.

Flowchart for the Operation of the Highspeed Monitor

The hardware modules which constitute the Instrumentation set-up for the High-Speed monitor are synchronized by LabVIEW modules, which are designed to push the acquired data files upstream by FTP from the onsite computer to a remote server for display on the world wide web and archival. The burdensome video frames are compressed into JPEG format before delivery. An estimated 200 kbps bandwidth is required by the bridge health monitoring system. The throughput achieved at the remote server depends upon the efficiency of the ADSL and the ISP, the onsite computer, the offsite server, and the data path over the Internet. In general, service should be sought which is at least twice the required bandwidth. It should be noted here that the LabVIEW drivers provided for the MEGADAC system limit our sensor sample rate to approximately 25 Hz. This may be sufficient to determine most of the critical state parameters for condition assessment (e.g., influence lines).

The remote server(s) has several implemented tasks, designed to minimize the necessary processing by the onsite computer that should be focused on data acquisition, packeting, and communication.

• Offsite Processing: The received data files are processed into the desired structural state, parameters and condition indices by custom LabVIEW procedures. Graphical displays of the received data and processed parameters are readily generated as needed for system maintenance, demonstration, further analysis, reports, or other communications. Existing displays include: video frame of bridge traffic, four selectable channels of scrolling bridge responses along a six (or other) second time axis, current and statistical graphs of vehicle speed, weight, and classification from the WIM scale, etc.

• World Wide Web (WWW) Server: LabVIEW supports the dynamic execution of a Common Gateway Interface (CGI) which posts and animates any LabVIEW display over the Internet. The displays are formatted as Portable Network Graphics (PNG) for lossless compression.

• Data Archival: The received data files and processed parameters are stored in a common format for future review and statistical analysis. This archive can easily require 1GB of storage space each month for an active regimen of bridge testing and condition assessment.

The onsite computer can also be directed to process and display the data files for the above instruments. This is particularly useful for onsite demonstrations. The analog modem also provides an alternative scheme for remote demonstration by phone line, but this is obviously a less impressive display due to its small bandwidth. Terminal emulation is presently achieved with the commercial software known as PCAnywhere. Some system control and maintenance needs are still most readily achieved by terminal emulation. Further, this allows a backup mechanism to debug any interruptions to Internet service and reinitialize the Internet connection without actually driving to the bridge site.