Last modified 5 months ago Last modified on 06/07/17 16:21:54

SIS-Central Functional Specification 2.0

SIS-Central aims to be a centralized metadata repository for various seismic networks.
  1. Repository (what should it store)
  2. Actions
  3. Reports and Products (data aggregation / report tools / output)
  4. User Interface (various interfaces to manipulate the data)
  5. Populating the Repository
  6. High-level Requirements


The repository should allow users to store the following types of metadata:

  1. Place/Site Information
    1. Place: ground where site(s) and related structures are located (place name, lat/long)
    2. Site
      1. Tag: Seismic, GPS, Telemetry Relay, or combinations of any two or all three
        1. IMPLEMENTATION DEPENDS ON FUNDING: GPS - Placeholder stubs for GPS included in schema, but implementation not expected for Phase 1.
      2. Descriptors: netcode, lookup code (not epoched)
      3. Descriptors: Operator, lat/long, altitude, landowner, contact, access-to-site, affiliation, funding, etc. (epoched)
    3. Maintenance (station logs)
    4. Channel
      1. Response (as specified by dataless SEED/CosmosV0 formats)
      2. Data problem reports
      3. Clip levels (datalogger, sensor, telemetry link)
    5. Equipment
      1. Instruments with response (sensors, loggers, amplifiers, VCOs, and discriminators) (i.e., affect channel response stages)
      2. Power systems
      3. Telemetry devices
      4. GPS devices (antenna, receiver)
      5. Other (Device hierarchy should be extensible to support new types)
      6. Equipment shared by multiple sites (e.g., shared power systems)
      7. Multi-station loggers/digitizers (e.g., logger located at one place but its response is used by many stations)
      8. Historic information should be preserved, with current equipment information being archived as the station is upgraded over time.
    6. Telemetry path (in development, Summer 2017)
      1. Network diagram
      2. Geolocated path segments (map diagram)
      3. IP Addresses
      4. Connection settings
    7. Supporting Documents (Links only, called "Custom Links"; not to be stored)
      1. Photos/diagrams
      2. Permit and NEPA documents
      3. FCC licenses
      4. Any desired external link, added by authorized users
      5. Any link to information that a particular RSN wants to reference from SIS, but which is desired to be kept private to that RSN
      6. User-created static/rich-text documents (e.g., Word files) related to:
        1. Station planning
        2. Station upgrades
    8. Station Aliases, to be used for COSMOS station number
    9. DEEMED OUT OF SCOPE on 9/24/2013: Station sets/‘lists’
  1. Instrument Information
    1. Operator - Each RSN requires their own equipment domain that should be isolated from one another. Equipment is foremost categorized by an RSN domain identifier.
    2. Equipment - Within an Operator, the equipment is further categorized by:
      1. Category (e.g., sensors, loggers, batteries, antennas, etc.)
      2. Owner/Organization
      3. Model
      4. Manufacturer
      5. Funding
      6. Inventory status
      A piece of equipment may be further categorized by unique serial number and/or owner-assigned property tag. The decision to track a particular set of equipment by serial number tag is at the discretion of the RSN.
    3. Maintenance
      1. Problem reports, e.g., repairs; Return Merchandise Authorization (RMA) reports
      2. Upgrades: System firmware (tracked via Settings)
      3. Removable hardware components (handled using Packages)
    4. Response (applicable for the seismic Equipment category) - SIS will represent the entire system so one can take the digital data and convert back to the observed signal. This will be represented in the following ways:
      1. Nominal gain
      2. Pole/zero (if applicable), e.g., sensors, amplifiers, analog filters, and IIR filters.
      3. FIR filters (if applicable)
      4. Polynomials
      If there is a nominal response in the NRL, SIS will store that.
    5. Supporting Documents - same as Custom Links (in this case, for Equipment), mentioned in 1g above
      1. Calibration sheets
      2. Manufacturer documentation
  1. Administrative / User information:
    1. Users: each RSN has its own user group. Users may belong to multiple RSNs and/or Organizations. Used for filtering equipment lists and inventory.
    2. LATER IMPLEMENTATION: Permissions: Within a group, each user is assigned various permissions that determine if the user is allowed to perform an action. The permission ruleset should be definable by each RSN.
  1. MUCH LATER IMPLEMENTATION (Long-term goal): Location and magnitude algorithm background information - with the ability to cross-reference this information to seismic station, but not specifically tied to such a station to allow the flexibility of different networks to use different values for the same station; versioning would be required
    1. Station delays
    2. Velocity models
    3. Magnitude corrections
    4. Amplitude-distance relations


  1. Equipment
    1. Install, swap, and remove equipment, and record any response change as a result
    2. Create new instruments and store settings
    3. Create and edit channel attributes
    4. Add or edit calibration
    5. Create new response sets
    Note: Certain equipment swaps may result in an epoch change.
  2. Channels
    1. Create and edit channel attributes
  3. Stations
    1. Create, update, or abandon site


  1. Generate reports for viewing - It is desirable for end-users to be able generate reports from the data in the repository without having to resort to SQL queries or similar low-level syntax.
  2. LATER IMPLEMENTATION: Programmatically query the repository for data that is input to another application - Some users may need to programmatically query SIS from another application. This requires a REST interface that defines specific URLs for various queries. The data exchange format is typically XML.
  3. Produce metadata in the following formats
    1. dataless SEED
    2. dataless V0
    3. StationXML
    4. LATER IMPLEMENTATION: XML for other datatypes outside the scope of StationXML (e.g., TelemetryXML)
  4. Error detection within the metadata - both during entry and after entry


Multiple user interfaces can connect to SIS-central. The basic dependency hierarchy of any user interface is as follows:

The User Interface (web/mobile/desktop) depends upon The Application Programming Interface (API, language-specific), which depends upon The Database-level Stored Procedures (PL/SQL), which rely upon The Database Objects (schema).


  1. Users should be able to query the database directly
  2. LATER IMPLEMENTATION: Users should be able to write their own scripts for obtaining and changing data
  3. User interface should have easily-accessible help available in the interface itself


  1. Import ability for all metadata that is not available in dataless SEED
  2. Import equipment response information using NRL
  3. Import ability via StationXML
  4. For a CMSM (centralized management system for metadata) to be useful in a multi-user environment, the system must present a consistent view of station and channel information at all times.


  1. Maximize accessibility and security
  2. Repository must accommodate non-USGS-funded stations
  3. LATER IMPLEMENTATION: RSNs should be able to write customizable modules (EXCEPTION: for StationXML)
  4. Full documentation for SIS (schema, GUI, APIs, scripts, etc.)
  5. Storage of all information that can be communicated via StationXML
  6. LATER IMPLEMENTATION: Make SIS a distributable system