1. SOC Physical Resource Allocations1 1

2. SOC-SDC Software Design
Matt Born

3. 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.

4. 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

5. SDC Data Retrieval Modules
The recipe:

6. 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]

7. 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.

8. 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

9. 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.

10. 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

11. SDC-PDP Data Processing Modules
The recipe:

12. 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

13. 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

14. SOC-PDP Monitoring of Critical Telemetry

15. SOC-SDC Trending of Critical Telemetry

16. 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.

17. 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

18. 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.

19. 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.

20. 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

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

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

23. SDC-NRT Near Real Time Analysis Tool Flight Usage

24. 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.

25. 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

26. 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.

27. 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.

28. 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.

29. 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.

30. 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

31. 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.

32. 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.

33. 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