CAPS

Redundant multi format data acquisition

Overview

What is CAPS?

About

The Common Acquisition Protocol Server (CAPS) was developed to fulfill the needs to transfer multi-sensor data from the station to the data center. As nowadays more and more stations with co-located sensors like broadband seismometer, accelerometer, CGPS, temperature, video cameras, etc. are build up, a acquisition protocol is required, which can efficiently handle low- and high-sampled data through one unified protocol.

Application

  • real-time data transmission from remote sensor to data center
  • center to center data transfer

Features

  • multi-sensor data transfer, e.g. waveform data, webcam images
  • redundant data transmission
  • ensures timeliness of data
  • on the fly reconfiguration
  • lightweight protocol for minimized packet overhead
  • archived and real-time data served through one protocol and one connection
  • reliable data transfer, retransmission of data in case of network outage or server restart
  • Web interface for server monitoring and data review
  • secure communication via SSL
  • fine-grained access control
  • connectivity to the SeisComP3 framework

Brochure  Documentation

 

Details

Timeliness of data

The focus on early warning in the last decade gave the timeliness of data a high priority. This made it necessary to allow backfilling of data (send most recent data first) as well as reducing the size of the data records. These requirements for data acquisition can not be fulfilled by many standard software packages. For example SeedLink, the de facto standard of real-time data transmission widely used to transmit seismic data, can neither handle backfilled data nor supports a variable record size. CAPS fills this gaps as it is format independent, which allows to handle low and high sampled data in parallel and uses index files to keep track of the timely order of packets.

Redundancy

In the last years one topic became a focal point of interest - redundancy. CAPS allows to fetch data packets through several connections in parallel, for example through a satellite line and Internet. Once the data is transmitted to CAPS, is is merged with the already available data set where duplicates are dropped. This allows full redundancy in data transmission and the only single point of failure left, is the equipment at the station itself.

Reconfiguration

One of the main problem for institutions handling massive data is the downtime during reconfiguration. CAPS reduces the downtime to an absolute minimum and at the same time takes care that no gaps in the data occur. This is realized through two approaches. One is the support of wildcard requests, the other is the buffering of data within the plugins. Wildcard request means, that CAPS can request all data available at the source and doesn't need a specific list of stations. Once the source adds a station, the data is directly transmitted to the target without the need to reconfigure or restart CAPS.

Architecture

Figure Architecture shows the architecture of CAPS. The central component is the server, which receives data from sensors or other data centers, stores it
into an archive and provides it to connected clients. The connection between a data provider and CAPS is made through a plugin.

Plugins are independent applications which, similar to clients, use a network socket to communicate with the server. The advantages of this loose coupling are:

  • Plugins may be developed independently and in a arbitrary programming language
  • A poorly written plugin does not crash the server
  • Plugins may run on different machines
  • Plugins may buffer data in case the server is temporary unavailable

Deployment

Figure Deployment illustrates a possible deployment of CAPS and its plugins. The acquisition of data from other data centers is most likely done through a public interface reachable over the Internet. For this center-to-center communication a plugin is typically launched on the receiving site to feed the local CAPS server.

For the direct acquisition of data from a sensor the plug-in has to run on the sensor station. This plug-in will send the data either directly to the data center or to local CAPS instance. The advantage of the second approach is:

  • Better protection against data loss: in case of a connectivity problem a local CAPS will store observations to the hard drive for later retrieval
  • Direct client access: a client may directly receive data from the sensor station
  • Less packet overhead: the CAPS client protocol is more lightweight than the plug-in protocol. A client packet only consists of a two byte header followed by the data

The ability to connect different CAPS instances simplifies sharing of data. One protocol and one implementation is used for the sensor-to-center and center-to-center communication. In the same way multiple CAPS instances may be operated in one data center on different hardware to create backups, establish redundancy or balance the server load.

Webinterface

web/channel view

CAPS ships with a read-only webinterface which provides server statistics and which lists available data streams.

The Overview shows (figure web/overview perspective) provides traffic data such as current uploadrate, received bytes and packages. On the right side the same traffic data is displayed as live charts allowing to instantly recognize changes in the data flow.

The Stream perspective shows all data streams including the time window of available data. The list may be filtered to easily find the streams of interest. Also time series data as well as image data may be instantly viewed by clicking on a particular channel entry (figure web/channel view).

Demo

Configuration

CAPS is developed as a standard SeisComP3 application. It uses the SeisComP3 infrastructure for startup and configuration. A GUI application
simplifies the setup and configuration tasks. In addition we offer a full featured web based configuration interface allowing you to control your installation from anywhere using any device running a web browser.

Plugins

Since CAPS entered the market more and more plugins have been developed. The most import once are:

  • caps2caps: Mirrors data between different CAPS instances
  • slink2caps: Reuse of SeedLink plugins, e.g. Chain, NAQS, WIN, SCREAM
  • rs2caps: Collects data from a SeisComP3 RecordStream. This plugin is very flexible since various data sources are already available through the SeisComP3 RecordStream interface
  • rtpd2caps: Imports data from a RTPD server (REF TEK)
  • ntrip2caps: Receives GPS data from a NTRIP Caster
  • v4l2caps: Connects an image or video device, e.g. a webcam