ABSTRACT

Real-time systems applied to seismic data acquisition, asynchronous processing, and data archiving tasks have clearly demonstrated their utility to the geophysical monitoring community. Many of the technological components have potential far beyond seismology, however. The need for real-time delivery of packetized data, integrated with processing, acquisition, and archiving systems is shared with many other signal domains used in environmental monitoring, including image acquisition, GPS surveys, weather monitoring, infrasound, and many more. As part of the UCSD ROADNet project, we have begun applying the Antelope Environmental Monitoring System to several of these new signal domains. We demonstrate prototype monitoring applications that integrate near-real-time, remote image acquisition from the Santa Margarita Ecological Reserve with the existing UCSD seismic data acquisition system. We discuss application of this technology to wireless acquisition of image, GPS, and real-time ship’s position and attitude data from the R/V Roger Revelle, in order to demonstrate the potential of the new monitoring technologies. Finally, we discuss the issues involved in generalizing the packet handling, namespaces, and data access issues for such generalized monitoring platforms.

Generalizing Seismic Processing Systems to Diverse Signal DomainsGeneralizing Seismic Processing Systems to Diverse Signal Domains

K.G. Lindquist *, F.L. Vernon †, T.S. Hansen ‡, A. Rajasekar ‡, B. Ludaescher ‡, J. Orcutt †, J. Berger †, H.W. Braun ‡, Y. Bock †

* Lindquist Consulting† Institute of Geophysics and Planetary Physics, UCSD (IGPP)‡ San Diego Supercomputer Center (SDSC)

System Structure

Antelope ORB

Packet Layer

Direct Data Sources Other Acquisition Systems

Real-time ProcessingPacket concatenation Delayed Processing

Real-time display Buffering and Archive DatabasesData Dissemination

Adding Signal Domains

In general, and in principle, each new signal domain needs:

•An orbpacket representation (with any encapsulation information)

•An unstuffed packet representation that represents it and all other members in

the same family (e.g. “all seismic waveform data” or “all weather data”)

•A set of routines that can stuff/unstuff the encapsulated to the unpacked

representations

•Direct acquisition utilities, i.e. datalogger2orb for each type of data source

•Virtual acquisition utilities, to connect to other real-time systems for that signal

domain

•A mechanism for concatenating packets, if concatenation makes sense for the

data stream

•A relational database representation (for a near-real-time buffer database;

possibly also for an archive database, which may or may not be a distinct format)

•A utility to take the orb stream into the database (e.g. orb2db for seismic data)

•A callback procedure to plot the data packet in a near-real-time display widget

•A graphical display utility or other display method (e.g. web page)

•Custom Processing utilities appropriate for the signal domain

•Export utilities to distribute data, possibly in protocols native to the signal

domain

Future Directions

Real-time Observatories Applications and Data management Network

What is VORB?

VORB = ORB + SRB

ORB: Object Ring Buffer

SRB: Storage Resource Broker

Real-time Observatories Applications and Data management Network

VORB • Aims

– Virtualized Access to Real Time Data Streams• VORB

– Virtualized Integration of Real Time Data• Multiple VORBs

– Private Virtual Real Time Data Management• Private VORBs

– Rapid ly Configurable RT Data Networks• Demand-driven Reconfigurable VORB

• Requirements– Federated Resource Brokering – Metadata Catalog– Rule-driven Data Aquisition and Integration– Extensible ORBs

Real-time Observatories Applications and Data management Network

VORB Components

actual data transfer

VORBArchive

VORBArchive

Event-Condition-Action Rules

Event-Condition-Action Rules

VORBCat

VORBCat

VORBRule Engine

VORBRule Engine

SrcORBSrcORB SrcORBSrcORBSrcORBSrcORB

Client/App.Client/App. Client/App.Client/App.Client/App.Client/App.

Future work falls into two categories: expansion and enhancement of the code to handle new signal domains; and virtualization of data access. The latter will be handled by combining the Antelope orbserver with the Storage Resource Broker (SRB) project at the San Diego Supercomputer Center. The three figures at right and below sketch the features and benefits of the prototype Virtual-ORB (VORB) implementation under development.

For more information:http://roadnet.ucsd.edu

Axis 2400 Video Servers

Santa Margarita Ecological Reserve

R/V Roger Revelle

The images above were both acquired from Axis 2400 video servers (Axis Communications, Inc.). The top image is from the Santa Margarita Ecological Reserve (south of Temecula, CA); the bottom image is from one of the research ships run by the Scripps Institute of Oceanography, the Research Vessel Roger Revelle. As with the Ricoh i700 images, the acquired pictures are placed on the orb alongside seismic data for telemetry and distribution, and displayed with the orbmonimg utility. The seismic stations shown are from the Anza array in Southern California.

GPS and Heading data from R/V Roger Revelle

The web-page snapshots above show GPS position and heading data from the R/V Roger Revelle, encoded as NMEA (National Marine Electronics Association) strings and delivered via the orbserver. In the case of this web page, a Common Gateway Interface (CGI) script connects directly to the orb to retrieve and display data. In more sophisticated, future applications, this will be mediated by a relational-database as a short-term buffer.

Real-time, Integrated Seismic and Image Monitoring

Ricoh i700 Internet Camera

Wireless Telemetry

Joint Seismic and Image Data Acquisition:Coronado Bridge Demonstration

These images show various aspects of simultaneous, real-time monitoring in multiple signal domains. All snapshots here were taken during the May 15, 2002 demonstration of seismic and visual instrumentation on the Coronado Bridge in San Diego. A wireless 802.11b IP network delivers near-real-time seismic data from a Kinemetrics episensor attached to a Quanterra Q330 datalogger, as well as near-real-time imagery from a Ricoh i700 internet camera. Time stamped packets are acquired and delivered to an integrated monitoring system based on the Antelope orbserver. A prototype real-time display utility, orbmonimg, shows all data as they come in.

The ultimate challenge for a real-time geophysical monitoring system is whether it can handle any type of sensor data which might be useful to incorporate: from seismic and infrasound to images, weather, GPS, Ocean Buoy data, stream level data etc. The figures below show the structure of a generalized monitoring system; the classes of software functions that need to be designed, in general, for the incorporation of new signal domains; and the some of the signal domains which our project will be working on.

Packet Namespace Conventions

Data packets on an Antelope orbserver can be any arbitrary binary objects, provided they have a timestamp (a UNIX epoch time) and a source-name (A character string of, at maximum, 63 characters). For seismic stations this takes the form

net_sta_chan/CODE/SUBCODEwhere CODE identifies the structure of the data-packet contents, with an optional SUBCODE for further classification. For the work described here we have been using the code “EXP” for “experimental,” while details of packet unstuffing are studied. The net_sta_chan part of the source name is replaced by namespace_sensor_sensorpart. An example might be SIO_Revelle_Gyro/EXP/NMEA for gyroscopic data from the R/V Roger Revelle.

Data Types to Incorporate•GPS data, ship location (NMEA strings): currently coming in

•SeaTex data from R/V Roger Revelle: currently coming in

•Gyroscopic data from R/V Roger Revelle: currently coming in

•Image data from Ricoh i700 cameras: currently coming in

•Image data from Axis 2400 video servers: currently coming in

•Campbell datalogger weather data: currently coming in, prototype

•Ashtech GPS data: incorporation in progress

•GPS RTCM data (differential corrections): planned

•Solinst stream-level logger: planned

•Handar weather-station data: planned

•CODAR radar wave-height measurements: planned

•Acoustic Doppler Current Profiler (ADCP) data: planned

•Other data types