SOC Physical Resource Allocations 1 1

SOC-SDC Software Design Matt Born mattborn@ssl.berkeley.edu

SDC-RET: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-RET Data Retrieval Modules Requirements: Retrieve data from external sources Deposit the data into an archive Log the transfer of data Operate within fixed latency bounds Design principles: Single “pull” interface per module Single “push” interface per module, always to ARC-INT Implementation: Python first draft C optimizations where required Most data transfers over SFTP per interface documents

SDC Data Retrieval Modules The recipe:

SDC-RET Data Retrieval Modules Module (CSCI) Retrieves From Using SDC-RET-MDP EFW SOC L0 RBSP MOC SFTP SDC-RET-MAG MOC EMFISIS MAG RAW, MOC EMFISIS MAG CAL RBSP EMFISIS SOC SDC-RET-ECT ECT SOC L2 RBSP ECT SOC SDC-RET-SCLK MOC SCLK SDC-RET-STATE MOC STATE SDC-RET-ANC MOC ANC SDC-RET-GEO [TBD]

SDC-ARC: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-ARC Data Storage Modules Requirements: Archive data from internal and external sources Log the source and time of deposited data Maintain previous versions of deposited data Design principles: No direct producer-to-consumer data transfer Separate archives for public data versus private data Implementation: Python first draft C optimizations where required At least HTTP and SSH access to archives

SDC-PDP: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-PDP Data Processing Modules Requirements: Synthesize new data products from existing ones Log the sources and methods used for data creation Deposit the data into an archive Operate within fixed latency bounds Design principles: No direct producer-to-consumer data transfer Fully automatic processes with no user intervention Implementation: Python first draft C optimizations where required Scripted execution of the NRT module for plot generation

SDC-PDP Data Processing Modules The recipe:

SDC-PDP Data Processing Modules CSCI Required Data Products Generated Data Products SDC-PDP-L0->L1 EFW SOC L0 EFW SOC L1 SDC-PDP-L1->L2 EFW SOC L1, EMFISIS SOC L0, MOC EMFISIS CAL, MOC EMFISIS RAW, EFW SOC MAINT, EFW SOC CAL, EFW SOC STATE EFW SOC L2 SDC-PDP-SOH EFW SOC MAINT SDC-PDP-STATE MOC STATE SDC-PDP-CAL EFW SOC L2, EFW SOC STATE, ECT SOC L0 EFW SOC CAL SDC-PDP-QL MOC EMFISIS CAL EFW SOC QL

SOC-PDP Data Products Product Contents Processing Volume L0 Raw telemetry - 130 MB/day/sat L1 Time-tagged raw waveform and spectral data (expressed in spinning-spacecraft coordinate system) Reformat from proprietary binary files to CDF 520 MB/day/sat L2 Calibrated waveform and spectral data (expressed in despun spacecraft coordinate system and other geophysical coordinate systems as required) Calibrate data and recalculate coordinates in despun spacecraft coordinate system 2.1 GB/day/sat L3 Calibrated waveform and spectral data with VxB subtraction for DC electric field estimates Subtract VxB (?) 3.1 GB/day/sat L4 Global electric field pattern ? Negligible

SOC-PDP Monitoring of Critical Telemetry

SOC-SDC Trending of Critical Telemetry

SDC-MET<->UTC: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-MET<->UTC Time Conversion Utility Requirements: Convert between times expressed in MET or UTC Validate conversions against canonical MOC conversions Design principles: Conversion speed is essential Implementation: Python first draft C optimizations where required At least HTTP access to service

SDC-MET<->UTC Time Conversion Utility Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-NRT: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-NRT Near Real Time Analysis Tool Requirements: Display waveforms and spectra Display header-level information Design principles: Leverage past project code base and IDL expertise Provide an extensible and usable tool for future re-use Implementation: IDL with Python extensions Integration of legacy code Scriptable operation

SDC-NRT Near Real Time Analysis Tool Instrument I&T Usage

SDC-NRT Near Real Time Analysis Tool Spacecraft I&T Usage

SDC-NRT Near Real Time Analysis Tool Flight Usage

SDC-BSEL: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-BSEL Burst Selection Utility Requirements: Allow selection of burst data by timestamp Log the selection of data Automatically select data if user declines to do so Implementation: Python first draft C optimizations where required Interface with CTG module for command generation

SDC-BSEL: Burst Selection Utility Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-BSEL: Burst Selection Utility Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-BSEL: Burst Selection Utility Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-DVAL: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-DVAL Data Validation and Release Requirements: Display data eligible for release along with data necessary to decide upon release Publish data deemed releasable Operate within fixed latency bounds Design principles: Reuse of existing modules for plot display Strictly controlled route between private and public archive Implementation: Python first draft C optimizations where required

SDC-DVAL Data Validation and Release Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-SDT: You Are Here Explanation of diagram: The CTG is what you might typically call the GSE. It is software that communicates with the instrument, either via the MOC or the SCE. It is the only part of the SOC that directly interfaces with the instrument. This module is responsible for generating instrument commands and receiving telemetry (in some configurations) and as such comes into play much earlier than other SOC modules because it is a key part of bringing the instrument up.

SDC-SDT Science Data Tools Requirements: Display and analyze waveforms and spectra Access data from the public archive, ARC-PUB We have determined that there exist numerous tools which will be applicable for scientific analysis of the instrument data. Software Package Supported by Notes SDC-NRT module RBSP EFW SOC Per requirements THEMIS Data Analysis Suite THEMIS SOC (core) and RBSP EFW SOC (extended) FAST “Science Data Tool” FAST SOC L1 and up, requires CDF format Autoplot NASA Virtual Observatories