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

Features

The core features of CAPS are:

  • Multi-sensor data transfer including miniSEED records, video streams and almost any other format.
  • No inventory required for immediate data acquisition.
  • Stations can be added without reconfiguring the CAPS server.
  • Pushing of data from new stations into CAPS without restarting the CAPS server.
  • Lightweight protocol for minimized packet overhead.
  • Archived and real-time data served through one protocol and one connection.
  • Reliable data transfer, re-transmission of data in case of network outage or server restart.
  • Backfilling of data and correct sorting by time even if they arrive in out of order sequences.
  • Secure communication via SSL.
  • Fine-grained access control.
  • Data redundancy.
  • Direct access to data via the caps RecordStream.
  • Native data supply via the Winston Wave Server, WWS protocol, e.g. to Swarm by USGS.
  • Native data supply using FDSN Web Services.
  • Server-side downsampling upon client request for optimized data transfer.
  • Web interface.
  • Telnet interface.
  • Provides data to Seedlink servers.

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.
../_images/architecture.png

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.
../_images/deployment.png

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.