wiki:SIS/FuncSpec/0.1
Last modified 4 years ago Last modified on 07/25/13 16:18:40

SIS-Central Functional Specification 0.1

Content last updated: 2012-08-03

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

REPOSITORY

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

  1. Station information
    1. Site-specific (landowner, contact, access-to-site, affiliation, funding, clock type, etc. - all of which will need epochs)
    2. Maintenance (site-visits, action-items)
    3. Channel
      1. Response (as specified by dataless SEED/CosmosV0 formats)
      2. Data problem reports
      3. Clip levels (datalogger, sensor, telemetry link)
    4. Equipment
      1. Instruments with response (i.e., affect channel response stages)
      2. Powersystems
      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., digitizers that handle multiple stations). Historic information should be preserved, with current equipment information becoming historic as the station is upgraded over time.
    5. Telemetry path
      1. Network diagram
      2. Geolocated path segments (map diagram)
    6. Supporting Documents
      1. Photos/diagrams
      2. User-created static/richtext documents (e.g., Word files) related to:
        1. Station planning
        2. Station upgrades
    7. Station Aliases (e.g. CI.BLY has alias Y12C for data export to TA network). When a station is imported by another RSN, it may be aliased differently from the stationcode used by the operating agency.
    8. Station set/‘lists’. The typical station set that a user from a particular RSN is interested in viewing metadata for contains:
      1. Stations operated by the RSN itself (both active, inactive)
      2. Active stations operated by another RSN, and imported to the user’s RSN.
      3. Inactive stations operated by another RSN but at one time imported to the user’s RSN

(Technical note: many-many relation between stations and RSNs that has ondate/offdate to track when the import began/ended.)

  1. Equipment information
    1. Domain - Each RSN requires their own equipment domain that should be isolated from one another. Equipment is foremost categorized by an RSN domain identifier.
    2. Inventory - Within a domain, the equipment is further categorized by:
      1. Hardwaretype (functional category)
      2. Owner agency
      3. Model/make (manufacturer)
      4. Devicetype (set of devices to which the piece of equipment belongs).
      A piece of equipment may be further categorized by unique serialnumber and/or owner-assigned propertytag. The decision to track a particular set of equipment by serialnumber tag is at the discretion of the RSN.
    3. Maintenance
      1. Repairs: Return Merchandise Authorization (RMA) reports
      2. Upgrades: System firmware and removable hardware components
    4. Response (applicable for the SEISMIC-INSTRUMENT hardwaretype)
      1. Nominal gain
      2. Pole/zero (if applicable)
      3. FIR filters (if applicable)
    5. Supporting Documents
      1. Calibration sheets
      2. Manufacturer documentation
  1. Administrative / User information:
    1. Users: each RSN has its own user group. Users may belong to multiple RSN domains.
    2. 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.
    3. Need the ability to keep certain types of information private to a specific RSN
  1. Long-term goal: location and magnitude algorithm background information - with the ability to cross-reference this information to stations, but not specifically tied to 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

REPORTS AND PRODUCTS

  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.

  1. Programatically 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.
  2. Produce metadata in the following formats
    1. dataless SEED
    2. dataless V0
    3. StationXML
    4. XML for other datatypes outside the scope of StationXML (e.g., TelemetryXML)
    5. CSS3.0
  3. Error detection within the metadata - both during entry and after entry

USER INTERFACE

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

  1. User interface (web/mobile/desktop) depends upon the

  1. Application programming interface (API, language-specific), which depends upon

  1. Database-level stored procedures (PL/SQL), which relies upon the

  1. Database objects (schema)

Additionally:

  1. Users should be able to query the database directly
  2. 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

POPULATING THE REPOSITORY

  1. Import ability for all metadata that is not available in dataless SEED
  2. Import ability via stationXML
  3. For a CMSM to be useful in a multi-user environment, the system must present a consistent view of station and channel information at all times.

HIGH-LEVEL REQUIREMENTS

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

Attachments