NOAA/seiscomp-training
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[installation] Init with inital config for global

Browse Source
This commit is contained in:
Dirk Rössler
2025-10-30 15:08:17 +01:00
commit 7640b452ed
3678 changed files with 2200095 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

160
share/doc/caps/html/_sources/base/introduction.rst.txt Normal file
View File

@ -0,0 +1,160 @@
.. _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.