Publications

This document is a guide to setting the system and processing configuration for the Geophysical Monitoring System (GMS) Station State-of-Health (SOH) Monitoring and Interactive Analysis (IAN) applications.

This document is a user’s manual for the Geophysical Monitoring System (GMS) Station State of Health (SOH) Monitoring User Interface.

This document is a user’s manual for the Geophysical Monitoring System (GMS) Interactive Analysis (IAN) User Interface.

Abstract not provided.

The Geophysical Monitoring System (GMS) State-of-Health User Interface (SOH UI) is a web-based application that allows a user to view and acknowledge the SOH status of stations in the GMS system. The SOH UI will primarily be used by the System Controller, who monitors and controls the system and external data connections. The System Controller uses the station SOH UIs to monitor, detect, and troubleshoot problems with station data availability and quality.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

The GMS Station State-of-Health (SOH) monitoring capability provides the system controller the ability to view current SOH values and calculated statistics for stations and channels, view trend plots of SOH values, be notified when station SOH status changes, and acknowledge or quiet notifications while the station issues are being investigated. The SOH monitoring capability includes components to acquire CD 1.1 protocol station data, extract SOH information from the raw data packets, process the raw SOH information for display, store the SOH information, and display the SOH information in an interactive display. All these components use system and processing configuration to provide the system controller mission-relevant information about station health. This document is a guide to setting the processing configuration for GMS SOH monitoring.

Abstract not provided.

Abstract not provided.

This document provides a "Build Guide" for a Generic Runnable System (GRS) of the Geophysical Monitoring Systems (GMS) common source code. This guide includes a list of software dependencies and licenses, hardware specifications, and instructions for how to build the system from the source code. The document is written for individuals who are experienced as administrators of Linux systems.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This document contains 31 use cases generated from the model contained in Rational Software Architect.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This document describes a conceptual Data Model for use in the IDC Re-Engineering development project.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This document contains 4 use case realizations generated from the model contained in Rational Software Architect. These use case realizations are the current versions of the realizations originally delivered in Elaboration Iteration 3.

Sandia National Laboratories has prepared a budgetary cost estimate for planning for the IDC Re-engineering Phase 3 effort, based on leveraging a fully funded, Sandia executed NDC Modernization project. This report provides the budgetary cost estimate and describes the methodology, assumptions, and cost model details used to create the budgetary cost estimate. Budgetary Cost Estimate Disclaimer This cost estimate is based upon a documented work scope that may not be complete at this time. This estimate may be used to develop budgets, includes a contingency appropriate for a budget estimate and does not represent a commitment to the estimate. If the project proceeds and the scope becomes better defined, a definitive estimate will be developed.

Abstract not provided.

Abstract not provided.

Sandia National Laboratories has prepared a project development plan that proposes how the parties interested in the IDC Re-Engineering system will coordinate its development, testing and transition to operations.

This document contains 21 use cases generated from the model contained in Rational Software Architect.

This document contains 21 use cases generated from the model contained in Rational Software Architect.

This document contains the system specifications derived to satisfy the system requirements found in the IDC System Requirements Document for the IDC Re-Engineering Phase 2 project. This System Specification Document (SSD) defines waveform data processing requirements for the International Data Centre (IDC) of the Comprehensive Nuclear Test Ban Treaty Organization (CTBTO). The routine processing includes characterization of events with the objective of screening out events considered to be consistent with natural phenomena or non-nuclear, man-made phenomena. This document does not address requirements concerning acquisition, processing and analysis of radionuclide data but does include requirements for the dissemination of radionuclide data and products.

This document contains the specific updates that were made to the 28 storyboards (UIS) that were deliverd to the IDC in Elaboration 1 and Elaboration 2.

This System Requirements Document (SRD) defines waveform data processing requirements for the International Data Centre (IDC) of the Comprehensive Nuclear Test Ban Treaty Organization (CTBTO). The IDC applies, on a routine basis, automatic processing methods and interactive analysis to raw International Monitoring System (IMS) data in order to produce, archive, and distribute standard IDC products on behalf of all States Parties. The routine processing includes characterization of events with the objective of screening out events considered to be consistent with natural phenomena or non-nuclear, man-made phenomena. This document does not address requirements concerning acquisition, processing and analysis of radionuclide data, but includes requirements for the dissemination of radionuclide data and products.

This document contains the specific updates that were made to the 42 use cases that were deliverd to the IDC in Elaboration 1 and Elaboration 2.

This document contains the glossary of terms used for the IDC Re-Engineering Phase 2 project. This version was created for Iteration E3. The IDC applies automatic processing methods in order to produce, archive, and distribute standard IDC products on behalf of all States Parties.

This document contains 4 use case realizations generated from the model contained in Rational Software Architect. These use case realizations are the current versions of the realizations originally delivered in Elaboration Iteration 1.

This document contains 4 use case realizations generated from the model contained in Rational Software Architect. These use case realizations are the current versions of the realizations originally delivered in Elaboration Iteration 2.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This architecturally significant use case describes how the System acquires meteorological data to build atmospheric models used in automatic and interactive processing of infrasound data. The System requests the latest available high-resolution global meteorological data from external data centers and puts it into the correct formats for generation of infrasound propagation models. The system moves the meteorological data from Data Acquisition Partition to the Data Processing Partition and stores the meteorological data. The System builds a new atmospheric model based on the meteorological data. This use case is architecturally significant because it describes acquiring meteorological data from various sources and creating dynamic atmospheric transmission model to support the prediction of infrasonic signal detection

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This document contains 3 use cases generated from the model contained in Rational Software Architect.

Abstract not provided.

This document contains 7 use cases generated from the model contained in Rational Software Architect.

This document contains the brief descriptions for the actors and use cases contained in the IDC Use Case Model.

This document contains 21 use cases generated from the model contained in Rational Software Architect.

Abstract not provided.

This document contains the Data Model generated from the model contained in Rational Software Architect.

This document contains the glossary of terms used for the IDC Re-Engineering Phase 2 project. This version was created for Iteration E1.

This document contains 4 use case realizations generated from the model contained in Rational Software Architect.

This document contains 7 use cases generated from the model contained in Rational Software Architect.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This System Requirements Document (SRD) defines waveform data processing requirements for the International Data Centre (IDC) of the Comprehensive Nuclear Test Ban Treaty Organization (CTBTO). The IDC applies, on a routine basis, automatic processing methods and interactive analysis to raw International Monitoring System (IMS) data in order to produce, archive, and distribute standard IDC products on behalf of all States Parties. The routine processing includes characterization of events with the objective of screening out events considered to be consistent with natural phenomena or non-nuclear, man-made phenomena. This document does not address requirements concerning acquisition, processing and analysis of radionuclide data but includes requirements for the dissemination of radionuclide data and products.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This document contains the brief descriptions for the actors and use cases contained in the IDC Use Case Model. REVISIONS Version Date Author/Team Revision Description Authorized by V1.0 12/2014 SNL IDC Reengineering Project Team Initial delivery M. Harris V1.1 2/2015 SNL IDC Reengineering Project Team Iteration I2 Review Comments M. Harris

This document contains the system specifications derived to satisfy the system requirements found in the IDC System Requirements Document for the IDC Reengineering Phase 2 project. Revisions Version Date Author/Team Revision Description Authorized by V1.0 12/2014 IDC Reengineering Project Team Initial delivery M. Harris V1.1 2/2015 IDC Reengineering Project Team Iteration I2 Review Comments M. Harris

The Comprehensive Nuclear-Test-Ban Treaty Organization (CTBTO) operates the International Data Centre (IDC) to support treaty verification activities by Member States. The IDC collects, stores, processes, and distributes data from seismic, hydroacoustic, infrasound, and radionuclide stations. A significant component of the IDC is the seismic, hydroacoustic, and infrasound (SHI) processing system. The IDC has recognized the need to reengineer the SHI processing system and has defined a three-phase reengineering effort. IDC Reengineering Phase 1 (RP1) started in 2011 with the goal to significantly modernize SHI automatic and interactive data processing software, focusing on enhancements to individual components of the system. Reengineering Phase 2 (RP2), started in 2014, addresses the task of specifying a unified architecture for all SHI software, across processing stages, to pave the way for further software development and sustainment in the future. A key objective of RP2 is an architecture sufficient to provide a basis for a cost estimate for the development or enhancement of the software components and subsystems. This report provides a brief description of the scope of the IDC Reengineering Phase 2 project. It describes the goals and objectives of reengineering, the system definition, and the technical scope of the system.This report expands upon the “Scope for IDC Reengineering Phase 2”, July 2014, ECS-DIS-WGB-43-PTS-MATERIAL-12-ADD-1, produced by the IDC.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Sandia National Laboratories has prepared a ROM cost estimate for budgetary planning for the IDC Reengineering Phase 2 & 3 effort, using a commercial software cost estimation tool calibrated to US industry performance parameters. This is not a cost estimate for Sandia to perform the project. This report provides the ROM cost estimate and describes the methodology, assumptions, and cost model details used to create the ROM cost estimate. ROM Cost Estimate Disclaimer Contained herein is a Rough Order of Magnitude (ROM) cost estimate that has been provided to enable initial planning for this proposed project. This ROM cost estimate is submitted to facilitate informal discussions in relation to this project and is NOT intended to commit Sandia National Laboratories (Sandia) or its resources. Furthermore, as a Federally Funded Research and Development Center (FFRDC), Sandia must be compliant with the Anti-Deficiency Act and operate on a full-cost recovery basis. Therefore, while Sandia, in conjunction with the Sponsor, will use best judgment to execute work and to address the highest risks and most important issues in order to effectively manage within cost constraints, this ROM estimate and any subsequent approved cost estimates are on a 'full-cost recovery' basis. Thus, work can neither commence nor continue unless adequate funding has been accepted and certified by DOE.

Abstract not provided.

This document contains the risk list for the IDC Reengineering Phase 2 project along with some background information related to the risk process.

This document contains the glossary of terms used for the IDC Reengineering Phase 2 project. This version was created for Iteration I2.

This is the IDC Re-Engineering Phase 2 project Integrated Master Plan (IMP). The IMP presents the major accomplishments planned over time to re-engineer the IDC system. The IMP and the associate Integrated Master Schedule (IMS) are used for planning, scheduling, executing, and tracking the project technical work efforts. REVISIONS Version Date Author/Team Revision Description Authorized by V1.0 12/2014 IDC Re- engineering Project Team Initial delivery M. Harris

This report is a progress update on the USNDC Modernization Service Oriented Architecture (SOA) study describing results from Inception Iteration 1, which occurred between October 2012 and March 2013. The goals during this phase are 1) discovering components of the system that have potential service implementations, 2) identifying applicable SOA patterns for data access, service interfaces, and service orchestration/choreography, and 3) understanding performance tradeoffs for various SOA patterns

This report is a progress update on the US NDC Modernization Service Oriented Architecture (SOA) study describing results from a proof of concept project completed from May through September 2013. Goals for this proof of concept are 1) gain experience configuring, using, and running an Enterprise Service Bus (ESB), 2) understand the implications of wrapping existing software in standardized interfaces for use as web services, and 3) gather performance metrics for a notional seismic event monitoring pipeline implemented using services with various data access and communication patterns. The proof of concept is a follow on to a previous SOA performance study. Work was performed by four undergraduate summer student interns under the guidance of Sandia staff.

This document contains the brief descriptions for the actors and use cases contained in the IDC Use Case Model Survey. REVISIONS Version Date Author/Team Revision Description Authorized by V1.0 12/2014 IDC Re- engineering Project Team Initial delivery M. Harris

Sandia National Laboratories has prepared a ROM cost estimate for budgetary planning for the IDC Reengineering Phase 2 & 3 effort, based on leveraging a fully funded, Sandia executed NDC Modernization project. This report provides the ROM cost estimate and describes the methodology, assumptions, and cost model details used to create the ROM cost estimate. ROM Cost Estimate Disclaimer Contained herein is a Rough Order of Magnitude (ROM) cost estimate that has been provided to enable initial planning for this proposed project. This ROM cost estimate is submitted to facilitate informal discussions in relation to this project and is NOT intended to commit Sandia National Laboratories (Sandia) or its resources. Furthermore, as a Federally Funded Research and Development Center (FFRDC), Sandia must be compliant with the Anti-Deficiency Act and operate on a full-cost recovery basis. Therefore, while Sandia, in conjunction with the Sponsor, will use best judgment to execute work and to address the highest risks and most important issues in order to effectively manage within cost constraints, this ROM estimate and any subsequent approved cost estimates are on a 'full-cost recovery' basis. Thus, work can neither commence nor continue unless adequate funding has been accepted and certified by DOE.

Sandia National Laboratories has prepared a cost estimate budgetary planning for the IDC Reengineering Phase 2 & 3 effort. This report provides the cost estimate and describes the methodology, assumptions, and cost model details used to create the cost estimate.

Abstract not provided.

In support of the International Data Center (IDC) Reengineering Phase 2 project, a list of proposed use cases with brief descriptions is provided for review.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Threats are generally much easier to list than to describe, and much easier to describe than to measure. As a result, many organizations list threats. Fewer describe them in useful terms, and still fewer measure them in meaningful ways. This is particularly true in the dynamic and nebulous domain of cyber threats - a domain that tends to resist easy measurement and, in some cases, appears to defy any measurement. We believe the problem is tractable. In this report we describe threat metrics and models for characterizing threats consistently and unambiguously. The purpose of this report is to support the Operational Threat Assessment (OTA) phase of risk and vulnerability assessment. To this end, we focus on the task of characterizing cyber threats using consistent threat metrics and models. In particular, we address threat metrics and models for describing malicious cyber threats to US FCEB agencies and systems.

Sandia National Laboratories has tested, evaluated and reported on the Geotech Smart24 data acquisition system with active Fortezza crypto card data signing and authentication in SAND2008-. One test, Input Terminated Noise, allows us to characterize the self-noise of the Smart24 system. By computing the power spectral density (PSD) of the input terminated noise time series data set and correcting for the instrument response of different seismometers, the resulting spectrum can be compared to the USGS new low noise model (NLNM) of Peterson (1996), and determine the ability of the matched system of seismometer and Smart24 to be quiet enough for any general deployment location. Four seismometer models were evaluated: the Streckeisen STS2-Low and High Gain, Guralp CMG3T and Geotech GS13 models. Each has a unique pass-band as defined by the frequency band of the instrument corrected noise spectrum that falls below the new low-noise model.

Most test methodologies referenced in this Test Definition and Test Procedures were designed by Sandia specifically for geophysical instrumentation evaluation. When appropriate, test instrumentation calibration is traceable to the National Institute for Standards Technology (NIST).

This Test Definition for the Evaluation of Digitizing Waveform Recorders (DWR) defines the process that can be performed as part of the evaluation and testing of geophysical sensors, digitizers, sensor subsystems and geophysical station/array systems. The objectives are to (1) evaluate the overall technical performance of the DWR, measure the distortions introduced by the high resolution digitizers and provide a performance check of the internal calibrator if provided and (2) evaluate the technical performance of the DWR for a specific sensor application. The results of these evaluations can be compared to the manufacturer's specifications and any relevant application requirements or specifications.

Most test methodologies referenced in this Test Definition and Test Procedures were designed by Sandia specifically for geophysical instrumentation evaluation. When appropriate, test instrumentation calibration is traceable to the National Institute for Standards Technology (NIST). The objectives are to evaluate the overall technical performance of the infrasound sensor. The results of these evaluations can be compared to the manufacturer's specifications and any relevant application requirements or specifications.

Abstract not provided.

Abstract not provided.

The process of developing the National Nuclear Security Administration (NNSA) Knowledge Base (KB) must result in high-quality Information Products in order to support activities for monitoring nuclear explosions consistent with United States treaty and testing moratoria monitoring missions. The validation, verification, and management of the Information Products is critical to successful scientific integration, and hence, will enable high-quality deliveries to be made to the United States National Data Center (USNDC) at the Air Force Technical Applications Center (AFTAC). As an Information Product passes through the steps necessary to become part of a delivery to AFTAC, domain experts (including technical KB Working Groups that comprise NNSA and DOE laboratory staff and the customer) will provide coordination and validation, where validation is the determination of relevance and scientific quality. Verification is the check for completeness and correctness, and will be performed by both the Knowledge Base Integrator and the Scientific Integrator with support from the Contributor providing two levels of testing to assure content integrity and performance. The Information Products and their contained data sets will be systematically tracked through the integration portion of their life cycle. The integration process, based on lessons learned during its initial implementations, is presented in this report.

Abstract not provided.

All stations planned for the International Monitoring System (IMS) must be certified by the Provisional Technical Secretariat (PTS) prior to acceptance to ensure that the monitoring stations initially meet the required specifications. Working Group B of the Preparatory Commission for the Comprehensive Nuclear-Test-Ban Treaty has established requirements for the quality, availability, and surety of data received at the International Data Centre (IDC). These requirements are verified by the PTS during a 3-component process that includes initial station assessment, testing and evaluation, and certification. Sandia National Laboratories has developed procedures, facilities, and tools that can be used to assist in evaluating IMS stations for compliance with certification requirements. System evaluation includes station design reviews, component testing, and operational testing of station equipment. Station design is evaluated for security and reliability considerations, and to ensure that operational procedures and documentation are adequate. Components of the station are tested for compliance with technical specifications, such as timing and noise levels of sampled data, and monitoring of tamper detection equipment. Data sent from the station in an IMS-standard format (CD-1 or IMS-1) are analyzed for compliance with the specified protocol and to ensure that the station data (sensor and state-of-health) are accurately transmitted. Data availability and authentication statistics are compiled and examined for problems.