161 lines
6.8 KiB
ReStructuredText
161 lines
6.8 KiB
ReStructuredText
.. _sec-intro:
|
|
|
|
Introduction
|
|
============
|
|
|
|
The Common Acquisition Protocol Server (|appname|) 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.
|
|
|
|
|appname| is a core component of |scname| systems where data redundancy, security
|
|
and high availability is key.
|
|
|
|
The |appname| package ships with
|
|
|
|
* The :ref:`CAPS server <sec-caps-config>` serving :term:`miniSEED <miniSeed>`
|
|
and other multi-format data in real-time and from archive.
|
|
* :ref:`Data acquisition plugins <sec-caps-plugins>` feeding data into the CAPS
|
|
server.
|
|
* :ref:`Data retrieval and analysis tools <sec-caps-retrieval>` including
|
|
on-demand access to data on the server.
|
|
|
|
|
|
Features
|
|
--------
|
|
|
|
The core features of |appname| are:
|
|
|
|
* Multi-sensor data transfer including miniSEED records, video streams and
|
|
:ref:`almost any other format <sec-packet-types>`.
|
|
* Compehensive data acquisition by all existing plugins for :cite:t:`seedlink`
|
|
plus additional :ref:`CAPS plugins <sec-caps-plugins>`.
|
|
* No inventory required for immediate data acquisition.
|
|
* Stations can be added without reconfiguring the |appname| 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 :term:`SDS` archives created by :cite:t:`scart` or :cite:t:`slarchive`.
|
|
|
|
* 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.
|
|
* :ref:`Data security <sec-caps-security>` on multiple levels:
|
|
|
|
* secure communication via :ref:`SSL <sec-conf-ssl>`.
|
|
* :ref:`User authentication <sec-conf-access-auth>`.
|
|
* different user and group roles distinguishing read, write or administrative
|
|
access.
|
|
* :ref:`fine-grained access control <sec-conf-access>` on service and stream
|
|
level for defined users, user groups or IP ranges.
|
|
|
|
* :ref:`Data redundancy <caps2caps>` by real-time connection between two or more
|
|
CAPS servers.
|
|
* Easy :ref:`access to data <sec-caps-retrieval>`:
|
|
|
|
* via the :ref:`caps RecordStream <sec-caps-recstream>` provided by
|
|
|scname| :cite:p:`seiscomp`
|
|
* using :ref:`added tools and interfaces <sec-caps-retrieval>` also offering
|
|
meta data information.
|
|
* via :ref:`Seedlink <sec-caps-seedlink>`.
|
|
* by built-in standard :ref:`FDSN Web Service <sec-caps-fdsnws>`.
|
|
* by built-in :ref:`Winston Wave Server, WWS <sec-caps-wws>`, e.g.,
|
|
to :cite:t:`swarm` by USGS.
|
|
* by an interactive :ref:`Web interface <sec-caps-web-interface>` also
|
|
offering statistics and meta data information.
|
|
* from :ref:`other CAPS servers <caps2caps>`.
|
|
* through :ref:`telnet interface <sec-caps-client-interface>`.
|
|
|
|
* Server-side downsampling upon client request for optimized data transfer.
|
|
|
|
|
|
.. _sec-architecture:
|
|
|
|
Architecture
|
|
------------
|
|
|
|
The figure below shows the architecture of :term:`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 :term:`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 |appname| by a firewall.
|
|
* Plugins may buffer data in case the server is temporary unavailable.
|
|
* A |appname| client library for C++ and Python may be provided upon request
|
|
allowing you to develop your own applications.
|
|
|
|
.. _fig-architecture:
|
|
|
|
.. figure:: media/architecture.*
|
|
:width: 16cm
|
|
|
|
Architecture of |appname|.
|
|
|
|
|
|
.. _sec-deploy:
|
|
|
|
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 :term:`SeedLink` or :term:`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 :term:`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 :term:`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 :ref:`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
|
|
:term:`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 :term:`CAPS` client
|
|
applications may be used in the field.
|
|
* **Less packet overhead** - The :term:`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.
|
|
|
|
.. _fig-deployment:
|
|
|
|
.. figure:: media/deployment.*
|
|
:width: 16cm
|
|
|
|
Possible deployment of |appname| and its components.
|
|
|
|
The ability to connect different :term:`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 :term:`CAPS` instances
|
|
may be operated in one data center on different hardware to create backups,
|
|
establish redundancy or balance the server load.
|