Introduction

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.

CAPS is a core component of SeisComP systems where data redundancy, security and high availability is key.

The CAPS package ships with

• The CAPS server serving miniSEED and other multi-format data in real-time and from archive.

• Data acquisition plugins feeding data into the CAPS server.

• Data retrieval and analysis tools including on-demand access to data on the server.

Features

The core features of CAPS are:

• Multi-sensor data transfer including miniSEED records, video streams and almost any other format.

• Compehensive data acquisition by all existing plugins for seedlink [17] plus additional CAPS plugins.

• No inventory required for immediate data acquisition.

• Stations can be added without reconfiguring the CAPS server avoiding server downtimes.

• Pushing of data from new stations into CAPS without restarting the CAPS server.

• Lightweight protocol for minimized packet overhead.

• Reliable data transfer, no data loss due to re-transmission of data in case of network outage or server restart.

• Archived and real-time data served through one single protocol and one connection.

• High-quality data archives:

  • backfilling of data and correct sorting by time even if records arrive in out of order sequences.

  • duplicate records in CAPS archives are impossible. Such duplicates may exist in SDS archives created by scart [12] or slarchive [18].

• Rapid response systems are supported by prioritizing recent data when recovering from longer gaps of data acquisition allowing to process the most recent data first before backfilling older data.

• Data security on multiple levels:

  • secure communication via SSL.

  • User authentication.

  • different user and group roles distinguishing read, write or administrative access.

  • fine-grained access control on service and stream level for defined users, user groups or IP ranges.

• Data redundancy by real-time connection between two or more CAPS servers.

• Easy access to data:

  • via the caps RecordStream provided by SeisComP [29]

  • using added tools and interfaces also offering meta data information.

  • via Seedlink.

  • by built-in standard FDSN Web Service.

  • by built-in Winston Wave Server, WWS, e.g., to SWARM [5] by USGS.

  • by an interactive Web interface also offering statistics and meta data information.

  • from other CAPS servers.

  • through telnet interface.

• Server-side downsampling upon client request for optimized data transfer.

Architecture

The figure below 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 no crash the whole server.

• Plugins may run on different machines to pull or push data. This allows to secure the access to the CAPS by a firewall.

• Plugins may buffer data in case the server is temporary unavailable.

• A CAPS client library for C++ and Python may be provided upon request allowing you to develop your own applications.

Architecture of CAPS.

Deployment

The acquisition of data from other data centers is most likely done through a public interface reachable over the Internet. For instance seismic waveform data is commonly distributed via SeedLink or ArcLink servers while the tide gage community shares its data through a Web interface. For this center-to-center communication a plugin is launched on the receiving site to feed the CAPS server.

For the direct acquisition of data from a sensor the plugin has to run on the sensor station. At this point the diagram distinguishes two cases: In the first example the plugin sends the data directly to the CAPS running at the data center. In the second case the data is send to a local CAPS server on the sensor station. From there it is fetch by the caps2caps plugin running at the data center.

The options for possible deployments are illustrated in the figure below.

The advantage of the second approach is:

• Better protection against data loss - In case of a connectivity problem plugins may transient buffer data. Nevertheless main memory is limited and the buffered data may be lost e.g. because of an power outage. 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. This is in particular useful for testing and validating the sensor readings during the station setup phase. The standard CAPS client applications may be used in the field.

• Less packet overhead - The CAPS client protocol is more lightweight than the plugin protocol. Once connected each data stream is identified by a unique number. A client packet only consists of a two byte header followed by the data.

Possible deployment of CAPS and its components.

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.