1. RBSP Radiation Belt Storm Probes RBSP Radiation Belt Storm Probes RBSP/EFW SOC-CDR 26 Jan 2010 665 EFW SOC Overview John Bonnell UC Berkeley jbonnell@ssl.berkeley.edu

2. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 666 EFW SOC Requirements The EFW SOC allows the EFW SOC and Science teams to: –Process and distribute EFW science data in a timely, accurate, secure, and configuration-controlled fashion. –Efficiently and securely command and control the EFW instrument, both during ground testing and on-orbit operations. Governing documents: –RBSP Mission Requirements Document. –RBSP-EFW UCB Performance Assurance Matrix (GSE, SOC, and IT Security tabs). –RBSP EFW SOC Requirements Document. –RBSP EFW SOC Software Development Plan. –RBSP EFW SOC Software Integration, Test, and Verification Plan. Contributing Documents: –RBSP Science Data Management Plan (SDMP).

3. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 667 EFW SOC Organization EFW PM Keith Goetz (UMN) EFW SysEng Michael Ludlam (UCB) EFW SOC Lead John Bonnell (UCB) EFW CTG Lead William Rachelson (UCB) EFW SDC Lead Matt Born (UCB) The EFW SOC will be: Developed at UCB. Hosted from UCB. UCB has played a similar role on previous missions: CRRES, Polar, FAST, THEMIS. EFW Instrument I&T occurs at UCB, and SOC development builds on the GSE required to support that effort: GSE→Test SOC→FLT SOC.

4. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 668 EFW SOC Changes Since I-PDR Action Item Status: All 5 SOC-related AI from EFW I-PDR have been responded to (Jan 2010). Text of responses available in Backup Materials. Changes: No major changes in SOC requirements or ICD. SOC-SDC Lead hired (Matt Born, May 2009). SOC-SDC CSCIs re-organized to consolidate by services provided, rather than by location along data path. Peer Reviews: Internal SOC (CTG and SDC) requirements review – Q4 2009.

5. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 669 EFW SOC Data Products Data LevelDescriptionTime to AvailabilityUsers L0Raw de-commutated, APID-separated telemetry data retrieved from MOC. Binary files. Typically daily retrieval and processing and/or reprocessing to pick up long-latency Burst data. Processing time < 6 hours. SOC, archives. L1L0 + Time-tagged RAW waveform and spectral in spinning spacecraft coordinate system. Software and CAL files read L1 data files and produce data in physical units. ISTP-Compliant CDFs. Daily production and/or re- processing. Processing time < 6 hours. Latency <= 7 days. SOC, EFW Team, archives. L2L1 + Time-tagged waveform and spectral data in calibrated physical units [V, mV/m, (V/m) 2 /Hz, etc.] in despun spacecraft coordinate system and relevant geophysical coordinate systems. ISTP-Compliant CDFs. QuickLook L2 data and Summary Plots. JPG and PDF (TBD) plot files (6 and 24-hr). Available internally daily for purposes of instrument operations and data validation. Pushed weekly or bi-weekly to MOC as validated by EFW-SOC and SCI teams. Latency <= 1 week. SOC, EFW Team, RBSP Science Team, Other End Users (Archives, Virtual Observatories, GIs, etc.). L3L2 + VxB removal for DC E-field estimate.Latency <= 1 month. L4L3 + global E field pattern estimatesLatency <= 1 year.

6. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 670 EFW SOC System Diagram GSE TEST-SOC FLIGHT-SOC

7. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 671 EFW SOC Data Processing Organization SOC is divided into two parts: Command, Telemetry, and Ground Support (CTG). Science Data Center (SDC) CTG consists of a one CSCI: CTG – Command, Telemetry, and Ground Support. SDC consists of eight CSCIs: NRT – Near-Real Time data processing and display. METUTC -- MET↔UTC Time Conversion. RET – Data Retrieval Services. ARC – Data Archiving Services. PDP – Processed Data Production (includes CALibration and State-Of-Health). DVAL – Data Validation. BSEL – Burst Data Selection. SDT – Science Data Analysis Tools.

8. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 672 EFW SOC CSCIs: CTG Command, Telemetry, and Ground Support (CTG): Interfaces with the EFW instrument, via: Spacecraft Emulator (SCE) MOC-SOC Interface Allows for commanding of the EFW instrument (uses FSW CTM database). Allows for acquisition of EFW instrument telemetry, both engineering and science, and archiving thereof, via services provided by the ARC CSCI.

9. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 673 EFW SOC CSCIs: NRT Near-Real Time data processing and display (NRT): Allows for the display of time-series (science and engineering) and spectral data products during Instrument- and SC-level INT, and On-Orbit Commissioning and Normal operations verses MET or UTC. Works off of PTP-format data files produced by CTG and stored in the archive via services of the ARC CSCI, or … fetched from MOC (e.g. L0 files), via services provided by the RET CSCI. Will be used for low-level analysis and verification of instrument data during nominal operations, as needed.

10. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 674 EFW SOC CSCIs: METUTC Mission Elapsed Time (MET) to UTC Conversion (METUTC): Allows for conversion of time stamps in MET to UTC. Allows for verification of local MET->UTC conversion. Current practice on EFW is to use “UNIX seconds” as MET (simple MET->UTC). Similar practice under consideration for SC-level INT. Full-up MET->UTC support postponed until “Week In the Life” Mission Sims.

11. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 675 EFW SOC CSCIs: RET and ARC Retrieval (RET): Allows for retrieval of data products from outside sources (MOC, other SOCs, other Geophysical or Operational data sources). Archive (ARC): Allows for controlled, structured storage of internal and external data products needed for EFW instrument operation. Allows for maintaining a private (EFW team only) and public (mission and general) archive partitions, to enable controlled release of validated data.

12. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 676 EFW SOC CSCIs: PDP Processed Data Products (PDP): Allows production of higher-level EFW instrument data products from lower-level data products; for example: Implements decommutation and time tagging of L0 data, and production of L1 CDFs (L0->L1). Implements calibration algorithms for EFW time-series and spectral data products (L1->L2). Implements coordinate system and frame transformations (L1->L2; L2-L3+): body-fixed (spinning) to quasi-inertial (non-spinning) coordinates. body-centered to geophysical coordinates. frame transformations (i.e. –VxB removal). Implements production of instrument State-Of-Health trend plots, and limit monitoring and alarms.

13. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 677 EFW SOC CSCIs: DVAL and BSEL Data Validation (DVAL): Allows the EFW Tohban (duty scientist) or SOC personnel to examine the most- recently acquired and processed EFW L2 data and validate that data for public release based on instrument State-Of-Health and lower-level data products, as needed. Burst Selection (BSEL): Allows the EFW Tohban (duty scientist) or SOC personnel to examine the available intervals of EFW Burst1 data and setup playback requests for desired intervals of that data, based upon EFW Survey and Burst2 data products, along with other geophysical data (RBSP instruments, ground data, etc.), as needed.

14. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 678 EFW SOC CSCIs: SDT Science Data Analysis Tool (SDT): Allows interested parties (EFW team scientists, other RBSP team members, scientists from the general public, etc.) to load, browse, and analyse data from the EFW instrument. Supports two legacy data analysis tools: EFI-related portions of the THEMIS Data Analysis System (IDL-based; THEMIS and other missions). The Science Data Tool (SDT) (C-based; Polar, Cluster). Will access other RBSP instrument data via L2, ISTP-Compliant CDF interfaces.

15. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 679 EFW SOC IT Security Information Technology (IT) Security requirements on the elements of the EFW SOC (CTG and SDC) are specified in the EFW UCB Performance Assurance Matrix. These requirements assure: –Secure commanding of and communication with the EFW instrument (CTG). –Secure serving of EFW instrument to the public (SDC). The driving IT Security requirements for the EFW SOC effort are: –Physical security of the commanding hardware: locked room with limited, known access list. –Access security to the commanding software: user training (password security, UC and EFW rules of conduct) password protection –Access security to the publically-served data: internet firewalls Read-only HTTP/SSH access –Access security to and backup of critical software: SVN repository with limited, known access list. SVN repository resides on SSL infrastructure, and is backed up daily.

16. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 680 EFW SOC Performance Assurance Performance Assurance (PA, aka. Quality Control) requirements on the elements of the EFW SOC (CTG and SDC) are specified in the EFW UCB Performance Assurance Matrix (Soft Dev-GSE; Soft Dev-SOC Operations; SoftDev-SOC Science). These requirements assure for the CTG and relevant elements of the SDC: –Best-practices for software development. –Verification and Validation of developed systems (hardware and software). The driving PA requirements for the EFW SOC effort are: –Configuration control of the developed/developing software: SVN repository. Bug reporting/tracking (EFW AI tracking; e-mail/xls). –Structured and informal SW Verification processes: SOC Integration, Test, and Verification plan (requirement-by-requirement ). Close day-to-day interaction between and cross-training of SOC and INT personnel (electrical and FSW).

17. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 681 EFW SOC Test Plan Baseline SOC test plan delivered (Jan 2010). CSCI elements will be tested in isolation to establish basic functionality (test cases; error cases and signaling). –Example: phased introduction of DCB and DFB functions and data products and testing using GSE. Elements are brought together into full modules and fed instrument data from known sensor excitations to verify module-level functionality and requirements fulfillment. –Example: basic functional tests during Instrument I&T. End-to-end testing at each stage of integration to weed out problems early. –Example: testing of complete PDP chain as early as possible during Phase D using data from SC I&T and environmental tests. MOC-SOC interface and EFW SOC design allows continued use of early tools, scripts, and code throughout lifecycle of instrument (GSE scripts are in the same language as SC-INT and Flight Ops scripts) User-facing CSCIs (SDT, BSEL, DVAL, etc.) will be supported with standard bug-reporting and tracking mechanisms (e-mail, bugzilla, etc.).

18. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 682 EFW SOC Development Plan: Schedule and Milestones PhaseCSCIs/ModulesMilestone Date (no later than) Supports I (Core Instrument Support) GSE CTG, NRT ARC-INT (CTG products only), Basic BSEL. Nov 2008 (initial ETU INT) Jul 2010 (EFW FLT INT) EFW IDPU ETU and FLT Board-Level Tests and Instrument I&T II (Core MOC Data Products) Test SOC Phase I + METUTC; RET-SCLK, -ANC, - MDP, -MAG. Feb 2011 - Basic MOC to test against needed Q3-Q4 2010. Spacecraft-Level INT III (Core SDC) Flight SOC Phase II + RET, PDP, ARC-PUB Apr 2011 (Launch – 12 months) - Basic MOC to test against needed Q3-Q4 2010. - Basic EMFISIS and ECT SOC (HOPE) to test against needed Q3-Q4 2010. Mission Sims (2+) MOC-SOC InterOperability. EFW Commissioning. IV (Full SDC) Flight SOC Phase III + DVAL, Full BSEL, SDT Launch + 60 days (Dec 2011) - MOC and EMFISIS and ECT SOC (HOPE) to test against needed Q2-Q3 2011. Normal Mission Ops.

19. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 683 EFW SOC Instrument and Mission Milestones ActivityDate EFW F1, F2 Instrument Integration (INT)Jul-Aug 2010 EFW F1, F2 Thermal Vacuum Testing (TVAC)Aug-Sep 2010 EFW F1, F2 CompleteOct 2010 EFW F1, F2 Delivery to APL for Spacecraft-level INT (SC-INT)Feb 2011 Mission Sim #1 (SC Sub-Systems only) Jan 2011 Mission Sim #2 Routine MOC-SOC Interactions EFW Commissioning Activities Apr 2011 Mission Sim #3 “Week in the Life of the SC and Instruments” Dec 2011 Mission Sim #4 “Launch Dress Rehearsal” Mar 2012 LaunchMid-May 2012 EFW Commissioning (Inst Turn-On, Check Out, SPB and AXB Deploy Ops) May-Jun 2012

20. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 684 BACKUP SLIDES

21. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 685 EFW SOC I-PDR SOC Action Items

22. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 686 EFW SOC AI-17: SOC Data Distribution to Public AI-17SOC Data Distribution to Public (Bonnell) Action: Make the distribution mechanism to the general public more explicit. There seems to be some THEMIS infrastructure for data distribution, but it is not clear how this will be adapted and used. Response: At the most basic level, the EFW L2 and higher data products (E-field waveforms and spectral data products in physical units, in geophysically-relevant coordinate systems, with nominal – VxB subtraction performed) will be available via HTTP (web-based acquisition of data files) and SSH (SFTP or SCP) from the EFW SOC Public Data Archive in ISTP-Compliant CDF files. Browse data in the form of daily or orbital summary plots of selected waveform and spectral data will also be made available to the public, as noted in the RBSP Science Data Management Plan. If a given public user utilizes the TDAS (THEMIS Data Analysis System) IDL-based data browser and analysis software, downloading of a given interval of L2+ EFW data will be handled by a straightforward specification of a time span and data products to retrieve. The software takes care of the SFTP transfer of the data files to the user ’ s local computer (via SSH), whereupon the TDAS routines load the data into TPLOT data structured for display and manipulation. The use of ISTP-Compliant CDFs for the public data allow users to utilize any other CDF-consuming data browsing or analysis platform that they wish, such as PAPCO, Autoplot, Science Data Tool (a legacy E-field data browsing, reduction, and analysis tool supported by the EFW team). Support for the TDAS-based and SDT-based methods of access and analysis will be provided by the EFW SOC team in the pre- and post-launch phases of RBSP. The EFW SOC team will also support distribution of the EFW data set through the RBSP Resident Mission Archive at the project level, along with Virtual Observatory cataloging of the EFW data, although the format of the RMA and VxO data remains to be determined.

23. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 687 EFW SOC AI-18: Coordination With Spacecraft Resources AI-18Coordination With Spacecraft Resources (Bonnell) Action: Address the coordination with spacecraft resources when generating commands/commanding instrument. For example, SSR allocation or telemetry rate limitations. Response: The only SC resources relevant to the SOC are allowed bit rate and response to the SSR fill state of the EFW partition. Power is the only other potentially-relevant on-orbit resource, and since the EFW instrument does not have explicit low power modes (it is either on or off with respect to both instrument and deploy power services), no complex commanding or response is designed into the instrument or flight software (FSW). In terms of response to the SSR fill state provided in the Instrument Time and Status message, the EFW instrument responds to an “ SSR Full ” state by curtailing all but real-time science and engineering telemetry. This leads to EFW Burst data that has already been stored in the EFW partition of the SSR being overwritten by real time EFW science and engineering data. It is felt that because of the typical fill margin enjoyed by the instruments during the mission (factor of two), a sophisticated response to the SSR Fill state would be overkill. If a more sophisticated response to the SSR Fill state is required due to unforeseen contingencies during the mission, the re-loadability of the EFW FSW from the ground can be used to add such features as needed. Tools will be available to the Science and SOC teams for estimating the daily data volumes produced by the instrument, and comparing those volumes to the EFW SSR allocation during the command testing phase (on the ETU test bed) that occurs prior to transmission of an EFW command load to the RBSP MOC. (continued, next page)

24. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 688 EFW SOC AI-18: Coordination With Spacecraft Resources AI-18Coordination With Spacecraft Resources (Bonnell) Response (con’t): In terms of controlling the average bit rate of data transferred from the EFW instrument to the SSR on-orbit, EFW follows a two-pronged approach. On-board, the EFW instrument FSW computes an average bit rate out of the EFW instrument to the SSR. This estimated bit rate is telemetered as engineering data. A command to the FSW sets a limit on the average bit rate to the SSR (12 kbps, from the MRD). APIDs that are assigned to real-time (continuous) output take up some fraction (typically 50%) of the allowed bit rate, depending upon commanded instrument configuration. The remainder of the bandwidth is available for burst data playback. The allocation of the remaining allowed bit rate between the two different types of EFW burst data (BURST1 and BURST2) is set by another FSW command. No on-board limiting of real-time APIDs is performed; i.e. if the instrument is commanded to produce 13-kbps of real-time data, it will happily do so. No burst data will be played back, in that case, however. Thus, the SOC team needs tools on the ground to estimate the bit rate produced by the instrument in a given configuration, both when developing new instrument configurations, as well as during the command testing phase, prior to transmission of a given command load to the RBSP-MOC. Currently, the EFW Command and Telemetry document (an excel spreadsheet) includes a bit rate calculator that takes the settings for the real-time and playback (burst) APIDs and computes the relevant bit rates, allowing one to determine the bit rate that a given instrument configuration would produce. Because the instrument bit rate estimate computed by FSW is available in engineering telemetry, the instrument operator can verify that the bit rate is as expected during the command testing phase, prior to transmission of a given command load to the RBSP-MOC. The EFW GSE also allows one to determine the aggregate RealTime, Engineering, BURST1, and BURST2 bit rates on-the-fly from the instrument, allowing one to verify that the bit rate is as expected, or diagnose which APID (and thus what part of the instrument configuration and commanding) is at fault.

25. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 689 EFW SOC AI-19: Data Product Naming and Version Ctrl AI-19SOC Data Product Naming Scheme and Version Control (Bonnell) Action: Either document or present the version/naming scheme for the data products. Present a plan of how versions will be managed, particularly for re-processed data. Response: L0 data fetched from the RBSP-MOC includes a version code as part of the file name, and that version code is bumped by one each time the L0 file is regenerated by the MOC (R. Barnes, e-mail, 12 Jan 2010). This is particularly relevant for the EFW Burst1 data products (waveforms), which can be pulled from a large Flash memory array from dates up to ~ 40 days in the past. L1+ data files include a version code in their file name as well, and the TDAS/IDL-based data acquisition and processing software recognize that version code, and default to acquire the file with the highest version number. The L1+ production routines will be triggered to produce a new version of their product files with incremented version code when a new L0 file appears, or the L0 file version is increased. The L1+ production routines will also produce product files with incremented version code if the processing algorithms are changed. An example of this would be development of an improved set of calibration parameters (this would impact the L1-L2+ processing), or the development of an improved bad data filter (this would impact L0->L1+ processing). Any changes to the production routines would first be validated on a sufficiently large subset of data in a controlled fashion, prior to allowing reprocessing of the entirety of the data set. Information about version changes will be communicated to the RBSP Science Team and the general public through the EFW Instrument Website.

26. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 690 EFW SOC AI-20: FLASH (Burst1) Memory Management AI-20SOC Flash Memory Data (Bonnell) Action: Explicitly reflect the software for telling the user what data is in the instrument flash memory and what has been downlinked already. SOC-user interface consideration. Response: The EFW SOC team and FSW lead developed a draft set of requirements and specifications for the FSW and SOC interfaces to the on- board Flash memory of the EFW instrument (RBSP_EFW_TN_037B_FlashManagement). In short: The FSW maintains a map on board of bad blocks in the Flash memory, produces engineering telemetry that can be processed by ground software into a UTC-to-pointer map for playback commanding, maintains a list of up to 128 playback starting points, and can dump table- of-contents information upon request for ground pointer map verification and reconstruction (if needed). The SOC processes the engineering telemetry into a UTC-to-pointer map that can be displayed along with other relevant geophysical data (survey data from EFW or other RBSP instruments; outside data, such as solar wind or Dst information; etc.), either in the IDL-based data browsers, or another TBD tool, to allow a designated member of the EFW Science Team (the Tohban, or Duty Scientist) to see: which time intervals of Burst1 data are present in FLASH; which have already been cued up for playback, but have not been played back yet; and, which have successfully played back to the ground. On the basis of that information, and the known data rate and volume allocations for the EFW instrument, the Tohban can manage the playback list (i.e. produce commands that will queue up the desired new intervals of BURST1 data for playback) to optimize the science return from the BURST1 FLASH memory system.

27. RBSP/EFW SOC-CDR 26 Jan 2010Bonnell 691 EFW SOC AI-21: EFW SOC Facilities AI-21SOC Facilities (Bonnell) Action: Provide information on SOC facilities. SOC facilities were not covered at all. At this point some information on SOC facilities should be available. Response: Currently, in support of the CTG (Command, Telemetry, and GSE) and SOC-NRT and ARC (near-real time display tool; archive processing) efforts on the SOC side, and ETU development and test, and integration on the instrument side, the EFW SOC consists of the following facilities (MATT, please correct the server hardware, as needed): 3Three Windows laptops, running the EFW GSEOS configuration that supports CTG. Two Linux servers; one holds the SOC software SVN repository, and another will contain all SDC CSCIs which operate as services (including ARC, RET, and PDP) within virtual machines (the ARC currently resides on the same physical machine as the SVN repository, but will migrate at a TBD date in the future). The separation of services between different virtual machines on the SOC servers will allow for scaling up in the future should certain services be found to be more intensive than others. The separation of development services (i.e. SVN and calendar) from deliverable services (i.e. data retrieval and processing) will prevent the inevitable flux of development from impacting mission-related services. This set of hardware will support the EFW SOC through the GSE and Test SOC configurations. For the flight SOC, two desktop Windows machines will be purchased to serve as the dedicated command workstations for RBSP-A and – B. These desktops will be placed in a physically-secure location (locked room) with appropriate firewall and access control, consistent with the IT Security clauses of the EFW Performance Assurance Matrix. Data analysis will occur on a variety of Windows or Linux-based platforms, running either IDL or SDT, or another data analysis tool of the user ’ s choice. The EFW SOC may make use of the UCB SSL MOC instrument operations personnel in support of Mission Sims and Flight Operations, depending upon the results of an on-going trade study (expected completion: Q2 2010). This would allow for use of existing 24-7 instrument alarm response infrastructure (limit checking, paging, etc.), without requiring the SOC and Science teams to take on the day- to-day commanding and SOH monitoring, as well as contingency response tasks during the main RBSP mission.