Download Slide 1

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Clusterpoint wikipedia , lookup

Big data wikipedia , lookup

Data Protection Act, 2012 wikipedia , lookup

Data model wikipedia , lookup

Data center wikipedia , lookup

Database model wikipedia , lookup

Data analysis wikipedia , lookup

Forecasting wikipedia , lookup

Data vault modeling wikipedia , lookup

Information privacy law wikipedia , lookup

3D optical data storage wikipedia , lookup

Business intelligence wikipedia , lookup

Transcript
Generalizing Seismic Processing Systems to Diverse Signal Domains
K.G. Lindquist
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.
*,
†,
‡,
‡,
‡,
†,
F.L. Vernon T.S. Hansen A. Rajasekar B. Ludaescher J. Orcutt J. Berger
* Lindquist Consulting
† Institute of Geophysics and Planetary Physics, UCSD (IGPP)
‡ San Diego Supercomputer Center (SDSC)
Joint Seismic and Image Data Acquisition:
Coronado Bridge Demonstration
†,
H.W. Braun
‡,
Y. Bock
†
Axis 2400 Video Servers
Santa Margarita Ecological Reserve
GPS and Heading data from R/V Roger Revelle
Ricoh i700
Internet Camera
Wireless Telemetry
R/V Roger Revelle
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.
Real-time, Integrated Seismic and Image Monitoring
System Structure
Direct Data Sources
Other Acquisition Systems
Antelope ORB
Packet Layer
Packet concatenation
Real-time display
Real-time Processing
Data Dissemination
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.
Delayed Processing
Buffering and Archive Databases
Adding Signal Domains
In general, and in principle, each new signal domain needs:
•An orbpacket representation (with any encapsulation information)
Future Directions
•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
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.
•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
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.
What is VORB?
VORB = ORB + SRB
ORB: Object Ring Buffer
SRB: Storage Resource Broker
Real-time Observatories Applications and Data management Network
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
Packet Namespace Conventions
• Aims
•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
For more information:
http://roadnet.ucsd.edu
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/SUBCODE
where 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.
VORB Components
VORB
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.
– 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
Client/App.
Client/App.
Event-ConditionEvent-ConditionAction
ActionRules
Rules
Client/App.
Client/App.
Client/App.
Client/App.
actual data transfer
VORB
VORB
Rule
Rule Engine
Engine
VORB
VORB
Cat
Cat
VORB
VORB
Archive
Archive
SrcORB
SrcORB
SrcORB
SrcORB
SrcORB
SrcORB
Real-time Observatories Applications and Data management Network