SDO Science Operations Working Group Meeting (SOWG #1) 21-22 October, 2004 Bldg 14 Room E280 Goddard Space Flight Center Greenbelt, MD.

SDO Science Operations Working Group Meeting (SOWG #1) October, Bldg 14 Room E280 Goddard Space Flight Center Greenbelt, MD

SOWG#1 Agenda

Participants Participants from GSFC Attendants from Instrument Teams
EVE Gail Tate Karen Turk Don Woodraska HMI/AIA Jesper Schou Rock Bush Jim Aloise Jerry Drake Jake Wolfson Dawn Myers Participants from GSFC Tom Bialas Bob Defazio Jeff Ferrara Peter Gonzales Deepak Kaul Steven Krietz Joe Howard Eliane Larduinat Dean Pesnell Wendy Morgenstern Bob Oertly Brett Sapper Vijaya Sonti Chris Spinolo Maureen Suckling Mke Uffer Missie Vess Craig Weikel Tom Anderson Jeff Condron Liz Citrin Jim Dowling Eric Grob Ray Pages John Ruffa Chad Salo Chris Silva Hun Tann John Vanblarcom

Roadmap to CDR Craig Weikel 21-22 October 2004

SDO GDS Road Map - DRAFT 9/24/04 CY 2004 CY 2005
Project & Element Reviews Sept 04 Oct 04 Nov 04 Dec 04 Jan 05 Feb 05 Mar 05 Apr 05 May 05 Flight Instrument Reviews HMI Peer Reviews HMI Instrument Critical Design Review (ICDR) EVE Peer Reviews EVE Instrument Critical Design Review (ICDR) AIA Peer Reviews AIA Instrument Critical Design Review (ICDR) Detailed Flt Designs & High-level SOC Designs Detailed SOC Designs HMI Peer Revs HMI ICDR Detailed Flt Designs & High-level SOC Designs Detailed SOC Designs EVE Peer Revs EVE ICDR Detailed Flt Designs & High-level SOC Designs Detailed SOC Designs AIA Peer Revs AIA ICDR Flight Spacecraft Subsystem Reviews Spacecraft Subsystem Critical Design Reviews Detailed Flt Designs Flt Subsystem Peer Revs SDO Project Reviews Observatory Critical Design Review High-level GS Designs SDO Project CDR Ground System Reviews Ground Subsystem Peer Reviews SDO Ground System Critical Design Review Detailed GS Designs GS Subsystem Peer Revs SDO GS CDR

SDO Communications Network
Chris Spinolo Jim Weidman 21-22 October 2004

Network Context Diagram

Network Context Diagram
Make device names consistent to facilitate discussion More detail, closer to final configuration Reduced component count by combining device functions No other network connections at a SOC T&C GSFC NOC controlled network. Please document all ancillary data flow requirements for the T&C.

SOC SDP Data Flows

SOC SDP Data Flows This baseline has No redundancy
Level of Service is “Premium” (not “Critical Real-time”) Outages dealt with by replays.

Critical Real Time Telemetry

Critical Real Time Telemetry
Entire data flow is redundant Each site (WSGT and STGT) has redundant RRCPs and network connections Each real time string selects which RRCP it connects to. Both real time strings get telemetry from their respective sites (WSGT or STGT) simultaneously FEDS#1 and FEDS#2 each feed both FEDS#3 and FEDS#4 FED#3 and FEDS#4 each serve real time telemetry sockets FED#3 and FEDS#4 each build level zero (complete and non-duplicate) product files.

Critical Real Time SOC Telemetry

Critical Real Time SOC Telemetry
Each SOC T&C connects to FEDS#3 or FED#4 for a telemetry feed A SOC T&C may connect to both FEDS for a simultaneous redundant feed (but don’t get carried away with your feeds) IP will be set up so that the critical telemetry feeds go to the SOC T&C’s via diverse (from the perspective of FEDS#3 and FEDS#4) paths.

HK Telemetry Distribution
All HK telemetry data is exchanged over sockets established between the MOC DMZ FEDS workstation and machines in the SOC-T&C and SOC-SDP Each SOC can have a total of 3 ASIST “users” SOC initializes a socket connection with DMZ FEDS Port 2001 (real-time) and Port 2051 (recorded telemetry) SOC initiates telemetry session (see MOC/SOC ICD) SOC sends a “self-identifying” message to the MOC MOC responds with an ACK/NAK MOC sends telemetry SFDUs

Failover for telemetry
MOC currently working on configuration and scenarios to provide automatic failover for failures of FEDS3/FEDS4, routers/switches Firewall Dual Communication lines to each SOC T&C

Non-encrypted Commanding
SOC Commanding: Flow SSH Tunnel Encrypted Commanding Non-encrypted Commanding

SOC Commanding: Session
All commanding data is exchanged through an SSH tunnel established between the MOC Primary ASIST workstation and the SOC commanding machine MOC initiates a SSH session to the SOC Ssh –l username soc.sdo.nasa.gov –R 2002: :2002 SSH session will create a tunnel between MOC and the SOC SOC opens a commanding session to a port local to the SOC Port 2002 Port picked up by SSH and passed to the MOC SOC initiates commanding session (see MOC/SOC ICD) SOC sends a “self-identifying” message to the MOC MOC responds with an ACK/NAK and enables commanding SOC/MOC are ready to exchange commanding messages

SOC Commanding: S/W and Config
What is needed? SSH2 Server on commanding stations Best on UNIX, Linux or Mac OS X, but can be purchased or compiled for Windows The SSH session will be initiated via a public/private key set.

SOC Commanding: Failover Scenarios
For most failures (MOC, routers, switches, firewall) Operator action is required (coordinated by voice) MOC reinitiates SSH Tunnel SOC reinitiates the commanding session

Network/Security Documentation
Process Research Risk assessment Security Plan Implementation Maintenance Documents Risk Assessment Disaster Recovery Plan

HMI & AIA JSOC Architecture
GSFC White Sands housekeeping LMSAL MOC DDS House- keeping Database Stanford HMI & AIA Operations AIA HMI HMI JSOC Pipeline Processing System Redundant Data Capture System Redundant Data Capture System Quicklook Viewing Catalog Primary Archive Local Archive 30-Day Archive AIA Analysis System High-Level Data Import Offsite Archive Offline Archive Data Export & Web Service World Science Team Forecast Centers EPO Public

FDS Products Bob Defazio 21-22 October 2004

FDS Products Product Transfer to SOCs
Finalize need list for each science team Updated list of FDS products sent to SOCs for review FDS generates products based on needs for both FOT and SOCs Only products of interest to SOCs will be provided to the SOCs SOCs to review and confirm products they need (done with EVE in June 2004) Identify all products that are of interest to SOCs Verify that no product needed by SOCs are missing from this list List of FDS-generated products must be finalized by GS CDR After GS CDR, Making existing FDS products available to SOCs may be done with a minor impact. Modifying products or adding new ones will have a much bigger impact Product Transfer to SOCs Products deposited on MOC Server. SOCs FTP “get” Products are replaced on MOC server when new version becomes available Ex: 5-week product updated weekly is deleted and replaced each week Formats and file naming conventions Defined in FDF to Ground System ICD to be finalized by GS CDR (Bob Defazio)

Bob Defazio provided samples of the FDS Products available to the SOCs

Instrument Calibration Maneuvers
Missie Vess ACS Analyst

EVE Cruciform Maneuver
Performed four times per year Off point +/- 2.5 degrees in Y/Z Step back towards zero in steps of approximately 3 arcmin Hold each position for 30 seconds 202 total points ACS requirement is 5 min to slew between each point ACS says that can be reduced to 2 min, except for the 4 – 2.5 degree slews Performed in Inertial Mode

EVE Field of View Map Performed four times per year
5 x 5 raster scan – +/- 10 arcmin in Y and Z Step size of approximately 5 arcmin Total of 26 steps (including return to (0,0) ) Hold each point for 1 minute ACS requirement is 5 minutes to slew between points ACS says that can be reduced to 2 minutes Performed in Inertial Mode

HMI/AIA Roll Maneuver Performed two times per year
360 degree roll about the sunline Step size of approximately 22.5 degrees Total of 16 steps Hold each point for 15 minutes ACS requirement is 15 minutes to slew between points ACS says that can be reduced to 10 minutes Performed in Science Mode

HMI/AIA Off-Point Maneuver
Performed two times per year Off-point approximately +/- 15 arcmin in Y and Z Variable step size between 100 and 350 arcsec Approximately 20 steps Hold each point for 5 minutes ACS requirement is 5 minutes to slew between points ACS says that can be reduced to 2 minutes Performed in Inertial Mode

AIA GT/PZT Calibrations
Performed 12 times per year Off-point approximately +/- 30 arcsec in Y and Z Variable step size between 5 and 30 arcsec Approximately 20 steps Hold each point for 1 to 5 minutes ACS requirement is 2 minutes to slew between points Performed in Science Mode Operational scenario has not been done.

Calibration maneuvers: Updated Durations
EVE Off point - Cruciform Estimated total duration: 9 hours EVE Off point - FOV Map Estimated total duration: 1hr 45 min HMI/AIA Roll maneuver Estimated total duration: 7.5 hours (unchanged) (Performed in science mode) HMI/AIA Off point - Flat field Estimated total duration: 2.5 hours AIA GT/PZT (monthly) Very rough estimate: 1.5 hour

Wendy Morgenstern, ACS Lead Missie Vess, ACS Analyst
Calibration Maneuver timelines (or “I’m giving her all she’s got, Cap’n”) Oct Science Operations Working Group (SOWG) Wendy Morgenstern, ACS Lead Missie Vess, ACS Analyst

Calibration maneuver requirements
Each Instrument ICDs’ Section 8.0 captures the calibration maneuver requirements. ACS Analysis team has shown we can manage tighter requirements and support faster maneuvers. Details follow but (briefly) ACS will complete steps of up to 350 arcsec (ex: HMI Flatfield) or smaller in ≤ 2 minutes. ACS will complete steps larger than 350 arcsec up to a few degrees (ex: 2.5 degree slew to beginning of EVE cruciform scan) in ≤ 5 minutes ACS will complete steps of several degrees (ex: 22.5 deg HMI roll maneuvers steps) in ≤ 10 minutes ‘Will complete’ means from command to change position until ACS has again settled to control required for science observations. Note - no longer need the ‘drive-by’ command sequence for raster scan maneuvers.

HMI ICD Comments to SDO-CCR-0182 recommends the following updates to HMI ICD (464-HMI-ICD-0002) HMI_REQ_ b [Roll Calibrations]: SDO shall complete the move between each dwell point of the HMI roll calibrations and settle to the pointing accuracy and jitter accuracy defined for ACS science mode in less than 10 [was 15] minutes. HMI_REQ_ c [Off-point calibrations]: SDO shall complete the move between each HMI off point calibration dwell positions [100 to 350 arcsec] and settle to the pointing accuracy and jitter accuracy defined in requirements HMI_REQ_ d-g in less than 2 [was 5] minutes.

AIA ICD Same changes at HMI ICD
Comments to SDO-CCR-0183 recommends the following updates to AIA ICD (464-AIA-ICD-0011) AIA_REQ_ b [Roll Calibrations]: SDO shall complete the move between each dwell point of the AIA roll calibrations and settle to the pointing accuracy and jitter accuracy defined for ACS science mode in less than 10 [was 15] minutes. AIA_REQ_ c [Off-point calibrations]: SDO shall complete the move between each AIA off point calibration dwell positions [100 to 350 arcsec] and settle to the pointing accuracy and jitter accuracy defined in requirements AIA_REQ_ d-g in less than 2 [was 5] minutes.

EVE ICD EVE ICD (464-EVE-ICD-0004) section 8 is not yet in the review cycle. Comments on the content of Draft#7 EVE_REQ_ c [Cruciform Scan]: SDO shall provide a rate of no greater than 6 arcsec/sec in a 30 second period during each EVE cruciform scan calibration point. We will not need the ‘drive-by’ approach. This requirement could be removed. Or, it could remain as it will be easily met by settling to the dwell position. Unlike AIA and HMI, EVE Cruciform scan requirements do not specify a maximum time to complete the move between points. ACS can complete the 3 arcminutes steps (EVE_REQ_ d) in ≤ 2 minutes EVE_REQ_ […]: FOV Maps 5 arcminute steps specified ( a), but requirements do not spec a time to complete the 5 arcminute move. ACS can complete the 5 arcminute (300 arcsec) steps in ≤ 2 minutes

Calibration Maneuver Operational Scenarios
Eliane Larduinat October 21 SOWG#1

HMI/AIA Off-Point Maneuver

HMI Roll Maneuver

EVE FOV Maneuver

EVE Cruciform Maneuver

Peter Gonzales Dean Pesnell October 21 SOWG#1
Data Completeness Peter Gonzales Dean Pesnell October 21 SOWG#1

Data Capture Budget – Data Capture Intervals
From Appendix-A of the LWS Program Plan, the Level One requirement reads: For HMI a valid “72 day interval” requires that 95% of data is captured (see MRD requirements) The prime mission lifetime is 5 years (not counting the launch & commissioning phase) How do we demonstrate that we can capture 95% of the HMI data for day periods within a five year span? The data capture budget is based on capturing 95% over a year and is not representative of the 72-day periods Some options for demonstrating our ability to meet the Level-1 requirement: 1st option - you can fit 25 consecutive 72 day periods in a 5 year span, 22 of those must meet 95% 2nd option - you can schedule planned events between 72-day science periods and show that you can fit 22 95% complete periods in a 5 year span

1st option - you can fit 25 consecutive 72 day periods in a 5 year span
you need 22, so you can loose up to 3 whole periods this is a difficult approach since there is little margin for error Figure 1 illustrates this approach, showing 25 consecutive 72-day periods and illustrates all outages from planned or known events (eclipses, maneuvers, etc) but does NOT include unplanned events (rain, SEUs, anomalies, etc.) Note: margin is required in each 72-day period to allow for unplanned events – as an example see figure 2 which includes the allocation for rain of 1.0% Figure 1 shows five (5) 72-day periods with little or no margin, leaving only 20 with a reasonable chance of success. This is not satisfactory. (In fact before the recent adjustments to the data capture budget (including adjustments to cal maneuver duration and delta-H recovery), 5 of the periods were not meeting the 95% requirement at all.) 2nd option - you can schedule planned events between 72-day science periods and show that you can fit 22 95% complete periods in a 5 year span Planed events which can be scheduled or moved (within reason), such as some of the longer instrument calibration maneuvers, can be scheduled between 72 day periods. Figure 3 is a very coarse representation of this approach with all instrument cal maneuvers removed (and gaps in between periods have not been included in the data). However, figure 3 still gives a sense of the margin available on each 72 day period to handle unplanned or unexpected events. One possible implementation of this approach is: Assume a 75 day operational cycle. Allocate 72 days for science data collection and allow 3 days each cycle to do (if necessary) any long intrusive calibration maneuvers and other plan-able events with large impact potential to data capture. Note: This would not mean, stop taking science for three days, it simply means, we would reserve 3 days at the end of each 72 day cycle to schedule events which might otherwise cause a 72 day period to be compromised if it were performed right in the middle of the 72-day period You can fit day operational cycles in 5 years with 176 days left over.

Figure 1 – 25 consecutive 72 day periods (planned outages only)

Figure 2 – 25 consecutive 72 day periods (planned outages plus 1% rain)

Figure 2 – 25 72 day periods with calibration maneuvers not shown

Data Control Format Document (DFCD)
Peter Gonzales Eliane Larduinat October 21 SOWG#1

DFCD Instrument Teams Responsibilities
DFCD Section 1.4 defines “Instrument T&C Database Responsibilities” DFCD complies with MOC-SOC ICD Section 6.1 (see attached for reference) For all CMD, TLM and STOL database information exchanged between the MOC and the SOCs RDL files will be used RDL file naming convention defined in this DFCD will be followed CMD and TLM mnemonic naming conventions defined in this DFCD will followed

DFCD Sections Applicable to the SOCs
Section 2, general database development overview Section 3, ASIST RDL files naming convention. All CMD and TLM DB exchanges must be in the form of RDL files RDL file format defined in ASIST User’s Guide SOCs must follow the RDL files naming convention defined in DFCD Sections 4 “TLM Mnemonic naming conventions and Section 5 “CMD Mnemonic naming conventions” Conventions must be followed in all exchanges of mnemonic information with the MOC (CMD and TLM DB RDL files as well as procedures) If SOC does not internally follow the naming conventions defined in DFCD. SOC must define a translation process for all Cmd and Tlm mnemonics Different conventions are transparent to the MOC

DFCD Sections Applicable to the SOCs
Section 6 “Telemetry Display Pages” Recommendations on page development. (not imperative) Section 7 “Procedure development” SOCs must conform to procedure template for all STOL procedures residing on or used by the ASIST MOC system Follow preamble/header comply with naming convention Following same conventions for SOC Internal procedures is strongly recommended Section 8 Database Configuration Management – SOCs will comply with the CM process described in this DFCD for All CMD, TLM and procedure files used by the MOC ASIST system SOCs may implement their own CM process at the SOCs

MOC/SOC ICD Project Database Section
6.1.4 Project database input and updates The MOC project database structure and formats will be defined in the SDO Database Format Control Document (Reference 6). This document also defines the way database files will be exchanged between the SOCs and the MOC during all mission phases. Database information between the SOCs and the MOC will be exchanged in the form of Record Definition Language (RDL) files. The format details are defined in Reference 6 and this information is not repeated in this document. Telemetry Definition Database The SOCs provide the instrument telemetry definition database related to the instrument telemetry parameters that the FOT monitors at the MOC. The MOC must be able to decommutate and process the S-band telemetry packets containing these parameters. Similarly, the MOC provides the SOCs with the telemetry database allowing them to process the spacecraft health and safety parameters they need to monitor. Command Definition Database The SOCs provide the MOC with the definition of the instrument commands the MOC needs to use or generate. This includes commands that the FOT may send as real-time commands from the MOC, or commands that will be used in spacecraft ATS loads, spacecraft RTS definitions or ground STOL procedures. The SOCs must also provide the information necessary for the MOC to recognize critical commands. This may be the full definition database for these commands or it may be reduced to a list of APID/Function codes for critical commands.

Mission Planning Brett Sapper, Vijaya Sonti,
Maureen Suckling, Steve Krietz October 21 SOWG#1

MPS Scheduling Scenarios
Long Range Planning (8 month): Long Range Files created from FDS S/W MPS gets LRPF From MOC IFS T0 LRPF ingested into Timeline and web-posted Auto once/day & Manual override Updates made on MPS Timeline User driven interactive window posted on web server S/W execution MPS Gets new LRPF from T0+3 months QPM reviews Timeline, and proposed updates Request ed to MPS Specialist Users verify, request any updates SDOGS/DDS S/C Engrs SOCs New LRPF ingested, Timeline updated The scheduling part of the mission planning system is less complex compared to some other missions, as: The instruments will looking at the sun, all the time -Mission planning responsibilities are distributed among the SOCs and FOT. - SOCs are responsible for the science planning. -SDO will have dedicated antenna’s and the ground network scheduling requirements are minimal. The coordinated activities like maneuvers are repetitive in nature. IFS = Internal File Server LRPF = Long Range Planning Files QPM = Quarterly Planning Meeting Timeline = single timeline with 8-month, 5-week, and weekly views

MPS Scheduling Scenarios (Cont)
Short-Term Planning (5 weeks): FDS generates set of 5 week planning files FDF 5wk products Delivered To MOC IFS Timeline for 5 Weeks reviewed at WPM Telecon with remote sites User driven S/W execution Final Ops Week Timeline approved and distributed MPS generates Daily OPS Sheets from Weekly Timeline MPS updates Timeline per WPM review interactive window WPM provides ICAL details to FOT for FDS or voice or mtg minutes WPM proposes Updates for non-OPS weeks SDOGS/DDS S/C Engrs SOCs USN MPS ingests files into Timeline and web is updated Auto once/day & Manual override ICAL = Instrument Calibrations (rolls, off-points) IFS = Internal File Server Timeline = single timeline with 8-month, monthly, and weekly views WPM = Weekly Planning Meeting

MPS Scheduling Scenarios (Cont)
ATS Load Generation Scenario FDS receives ICAL inputs from WPM (If required) FDS receives approved Weekly Timeline Printout delivered to FDS Specialist FDS generates activity command files FDS S/W generation with manual data entry Activity occurs with appropriate Console Team actions Console Team uplinks loads, executes STOLs, or monitors as needed based on daily activity sheet MPS generates loads and integrated prints using ASIST SCLG User driven S/W execution User load input requests: FSW, SOCs, FOT, or other MPS processes With predefined load templates MPS gets Command files From MOC IFS The scheduling part of the mission planning system is less complex compared to some other missions, as: The instruments will looking at the sun, all the time -Mission planning responsibilities are distributed among the SOCs and FOT. - SOCs are responsible for the science planning. -SDO will have dedicated antenna’s and the ground network scheduling requirements are minimal. The coordinated activities like maneuvers are repetitive in nature. CAM approves activity based on integrated print Distributed via Product server prior to CAM CAM = Command Authorization Meeting ICAL = Instrument Calibration IFS = Internal File Server SCLG = Stored Command Load Generator Timeline = timeline with 8-month, monthly, weekly views WPM = Weekly Planning Meeting

Long Term Planning (8 months)
FDS provides long range planning file every 3 months, containing placeholders for known events for the next 8 months (contains approximate dates) Long Range Predicted Eclipses (# 2) Long Range Predicted HGA View Periods of SDOGS (#9) Long Range Predicted RFI (#12) Long Range Maneuver Planning File (#17) [Stationkeeping maneuvers] Long range timeline is posted on web for all SDO users User inputs/updates are sent to FOT/MPS specialist for manual calendar update SDOGS downtimes (i.e. Preventative Maintenance) S/C Maintenance Activities (FSW dumps, Sensor Calibrations etc.) Instrument Calibration (ICAL) Requests (requested date for event) Rocket Flights (calibration rockets) Quarterly Planning Meetings (QPM) occur every 3 months, following long range product delivery by 1-2 days

Short Term Planning (5 weeks)
Each week, FDS provides a set of planning files for the next 5 weeks for the following activities: (Wednesday delivery for following week) (contains predicted details of the operation) Maneuver Planning File (#16) Momentum Management Planning Aid (#32) Predicted Eclipses (#1) Predicted HGA View Periods of SDOGS (#8A) Predicted RFI (#11) Predicted Attitude Dependent Ground Station Visibility (#7) [Omni Nulls] Ascending Nodes (#5) Descending Nodes (#6) Sensor Interference (#18) Celestial Bodies in Instrument FOV (#27) USN schedule inputs are received from USN and manually entered into timeline After weekly FDS delivery, a Weekly Planning Meeting teleconference takes place using the timeline as the basis for discussion: Weekly view used to confirm schedule of activities for the next week 5-week view is used to discuss schedule of subsequent weeks Activity level constraints (timing issues) are visually verified for all weeks FDS specialist creates appropriate command files for operational week, (and other associated products, as required) based on the times in the weekly timeline, and delivers the command files electronically to the MPS MPS timeline is updated with the time and duration of the activity from the FDS command file

Short Term Planning (cont.)
MPS performs any necessary file processing and initiates load generation MPS uses the ASIST SCLG (stored command load generator) to generate load and integrated print Integrated print is used at CAM (command authorization meeting) for approval of activity (CAM is scheduled 1 day prior to activity) Daily operations sheet is generated with appropriate information as required The Console Team performs any necessary actions (monitoring, STOL, Loads, uplink handover, etc.) on the day of the scheduled event

Ground System Readiness Testing
Solar Dynamics Observatory Ground System Readiness Testing Jeffrey Ferrara Robert Oertly

Ground System Readiness Process Flow
The Ground System Readiness Process is led by the Ground System Readiness Test Manager. The process is implemented through a test team comprised of all ground system elements. Test team members participate in all relevant test team meetings and reviews We need a representative from each SOC as a member of the test team to assure successful verification and scheduling. New Ground System Test Planning Acceptance Testing GS Integration Testing Simulations Ground System Ready

GSRT Documents Ground System Readiness Test (GSRT) Plan
The GSRT Plan’s main objective is to integrate and test the ground system according to Level 3 requirements The GSRT Plan draft will be out for project review at the end of 2004 It will contain our test descriptions and requirements tracking documentation Element Acceptance Test Plans Acceptance Test Plans are an integral part of the GSRT process We use element AT plans and schedules in our test planning We use the SOC test plans in SOC integration and test efforts Test documentation Pre-test briefings Post-test debriefings Test Reports Discrepancy Reports

GSRT Testing Spacecraft I&T MOC with the SOCs
Monitoring Interfaces with ASIST at the I&T area Interfaces with the DDS Prototype Capturing of science data for GSRT testing (working with DDS personnel) Testing T&C with the MOC MOC with the SOCs Interfaces; data, voice, paging Realtime T&C operations (with SDOGS, USN, SN) Mission Planning Product transfer/retrieval from servers (MOC; FDF, MPS, ITPS) Review Element 2810 Security audits pre-integration

GSRT Testing continued
DDS with the SOCs Interfaces; data, voice (comm line switching) Science Data Transfer to SOCs from DDS (some including SDOGS) Acknowledgements, reports and replay directives from the SOCs Long Duration reliability dataflow stress tests SOC science processing and product distribution Launch and Simulations Test SOC equipment operations in the MOC E-T-E Launch tests with SDOGS, USN, SN, KSC (launch facility) FOT Spacecraft Tests, Simulations and Operational Readiness Tests Problem Reporting Response SOC Internal GSRT PR/PFR

Schedule I&T Integration MOC/SOC Integration DDS/SOC Integration
2005 for DDS to IGSE Prototype testing (create recorded science data media) 2006 for I&T IGSE and ASIST MOC/SOC Integration Lines are scheduled to be in by 3/06 GSRT #1 Telemetry & Command – start 6/06 DDS/SOC Integration Lines are scheduled to be in by12/06 GSRT #2 Science Processing – start 1/07 GSRT #4 Integrated Ground system end-to-end – start 3/07 Simulations and Launch Configuration Tests Begin Mid 2007 CY05 CY06 CY07 CY08 DDS Prototype TRR I&T T&C SCI ETE SIMs Launch

Instrument Commissioning
Eliane Larduinat, Joe Howard October 21 SOWG#1

Commissioning phase is 90 days starting at Launch SOC personnel operating from their T&C equipment in the MOC send commands monitor the resulting telemetry in real-time progressive transfer of operations to the SOCs All instrument commissioning activities coordinated with FOT and rehearsed as much as possible prior to launch scheduled in advance allocated dedicated time if critical Procedures prepared in advance, coordinated with the FOT, and rehearsed during Observatory testing phase (especially thermal vac)

Instruments are powered off for launch Survival heaters thermostatically controlled Decontamination heaters Turned on as soon as possible after power positive (TBD) Duration (TBD) Instruments powered on during or after orbit circularization (TBD) Begin instrument checkout only after reaching orbit (L+12 days) HGA and KA band operational once on station (L+12 days minimum) Finish large maneuvers before opening doors Open doors after being on station One instrument at a time with time for verification Subsystems to be checked out thermal, main processor, HSB I/F, TBD mechanisms stabilization, cameras First light Internal calibrations

Instrument Commissioning: calibration maneuvers
After individual internal calibrations Perform each calibration maneuver at least twice successfully Proceed from less complex to most complex Allow time between each maneuver for thorough evaluation Proposed sequence of maneuvers: AIA Long form GT calibration EVE Flat field (daily) calibration (repeat routinely after 2 successes) AIA short form (monthly) GT calibration EVE FOV EVE Cruciform HMI/AIA Roll

Work that still needs done
Identify dependencies and constraints Add sufficient contingency time Define approximate durations Identify monitoring needs Identify contingency possibilities

Finish Orbit insertion
Launch Power S/C for Orbit raising Turn on Heaters For contamination protection Finish Orbit insertion Test Spacecraft components Power on instruments And open doors Deploy and Calibrate HGA Test Instrument functions Start Calibrations

Calibrations AIA GT Long form calibration EVE Flatfields
(daily and internal) HMI internal cal (first of daily) HMI/AIA off point Flat field HMI Focus Cal (first of bi-weekly) AIA non-maneuver EVE FOV HMI/AIA Roll EVE Cruciform

Instrument Commissioning Timeline (1 of 2)

Instrument Commissioning Timeline (2 of 2)

Flight Operations Plan and Operations Agreement Documents
Brett Sapper October 21 SOWG#1

FOP Vs OA Flight Operations Plan Operations Agreements
What observatory operations need to be performed and when or how often Detailed Description of how observatory operations are performed Descriptions and operations of GS elements and subsystems Contingency philosophy Trending philosophy FOT organization and structure Operations Agreements Specifies how and when products are exchanged (as identified in ICD) Specifies how long products are available Describes generation and exchange of operations reports Contact information Pre-approved responses to instrument contingency situations Nominal staffing and level of effort Data recovery scenarios

Operations Document Hierarchy
OPS Concept Document FOP: Identifies what observatory operations need to be performed, how often, and how they are supported by the Ground System and operations teams (MOC and SOCs). CCB Controlled. FOP ICD: Defines the detailed data structures for the products exchanged between two operational elements including transfer media and protocols, formats, file naming conventions, and field definitions. CCB Controlled. ICD OA: Documents the division of responsibility between the MOC FOT and the Science Operations Teams for nominal and contingency operations. Also identifies operational timelines with regard to the products exchanged (consistent with the ICD), how and when they are exchanged or made available. Signature Controlled. (instrument specific document) OA LOP: Detailed instructions on how to perform a specific activity or operation. Includes reference to STOL procs, UNIX shell scripts, and other programs, directives or activities used to execute a given operation. Signature Controlled. LOP

Detailed outlines of the FOP and one OA were provided at the meeting

SDO Science Operations Working Group Meeting (SOWG #1) 21-22 October, 2004 Bldg 14 Room E280 Goddard Space Flight Center Greenbelt, MD.

Similar presentations

Presentation on theme: "SDO Science Operations Working Group Meeting (SOWG #1) 21-22 October, 2004 Bldg 14 Room E280 Goddard Space Flight Center Greenbelt, MD."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SDO Science Operations Working Group Meeting (SOWG #1) 21-22 October, 2004 Bldg 14 Room E280 Goddard Space Flight Center Greenbelt, MD.

Similar presentations

Presentation on theme: "SDO Science Operations Working Group Meeting (SOWG #1) 21-22 October, 2004 Bldg 14 Room E280 Goddard Space Flight Center Greenbelt, MD."— Presentation transcript:

Similar presentations

About project

Feedback