1. Mission Systems Overview
John Ruffa
SDO Mission Systems Engineer

2. SDO Mission Top-Level Overview
SDO spacecraft intended to carry a suite of solar observation instruments to monitor and downlink continuous, real time science data from the sun and distribute to Instrument analysis sites
Geosynchronous orbit to allow continuous downlink line-of-sight to dedicated ground station for continuous downlink capability
Observatory Operations via typical S-Band system
Ka-band Science downlink required to meet anticipated ~130 Mbps science data rate (~300 Mbps final downlink symbol rate)
Real time downlink with no on-board science storage envisioned
High speed data pipeline from ground station to instrument analysis sites
“Get to orbit, stay pointed at the Sun, pump the data back”
Intended for 5 year Mission Life
Propellant provided for 10 year operational life

3. SDO Implementation Design Driver Overview
High data volume, coupled with tight requirements on data loss and degradation
High data rate, data interruption & loss requirements are a significant driver to S/C, ground system, and ops concept
Ka-band downlink selected to support bandwidth, high-volume data transfer from ground station to instrument SOCs
Mission architecture designed to address data completeness reqs
Mitigated by data capture budget, system design architecture, operations concept
Geosynchronous orbit
Selected to support continuous data downlink capability
Drives mass, launch vehicle, and propulsion issues
Places SDO in severe radiation environment
Mitigated by clear mass and prop budgets, ops concept, environments definition
Long mission life (5 year requirement, 10 year goal)
Mission life drives mechanism reliability, radiation requirements, failure concerns
Mitigated by life testing, redundancy, fault tolerance
Instrument pointing and stability
Number of pointing, alignment, and stabilization issues that need to be addressed in order to meet instrument requirements
Fine pointing, jitter characterization and compensation using instrument guide telescope
Driven by mechanical deformation & thermal stability, S/C and instrument boresight alignment requirements
Mitigated by mechanical/thermal design, detailed alignment budget, pointing & jitter analysis and budget

4. Geosynchronous Orbit Insertion
Once SDO placed in geosynchronous transfer orbit (GTO), orbit circularization propulsion system required to circularize to geosynchronous orbit
~36,000 Km
Geosynchronous orbit
~36,000 Km apogee
~36,000 Km
~36,000 Km
MEO orbital range
(~1,500-20,000 Km)
- Higher trapped proton environ.
(greater chance of SEE)
- Higher TID environment
~300 Km perigee
- Inclined GEO orbit selected to minimize eclipse interruptions, eliminate need for North-South stationkeeping and maximize launch vehicle capability
- Baseline launch and orbit circularization concept
- Baseline launch vehicle- Delta IV or Atlas V 401 series
- Bi-propellant propulsion system selected to circularize orbit

5. SDO Eclipse Season
The proposed SDO geosynchronous orbit will result in two eclipse seasons with a variable daily eclipse each day
The two eclipse seasons will occur twice a year due to the effects of the orbit geometry and the earth-sun position
During each eclipse season (~23 days), SDO will move through the earth’s shadow- this shadow period will grow to a maximum of ~72 minutes per day, then subside accordingly as the earth-sun geometry moves out of the SDO eclipse season
Eclipse season effects:
Instrument-
Interruption to SDO science collection
Thermal impacts to instrument optical system due to eclipse
Power-
Temporary loss of power from solar arrays
Battery sizing study includes eclipse impact
Thermal
S/C thermal design considerations due to semi-annual eclipses

6. SDO Science Data Path Implementation & Flow
Observatory science data collection:
- No Data recorder, dramatically easing overall system complexity & cost
- Data loss allocations characterized in data capture budget meet instrument science requirements
- BER allocation for Radiation SEE data loss
Dual antenna sites (SDO dedicated):
Both antennas actively receiving & transferring data to DDS
Geographically diverse (3 miles) to address localized rain attenuation
Each antenna has 48 hr data buffer to avoid data loss in transferring data to ground station DDS
Dual antennas dramatically increase system reliability, remove need for more costly, higher reliability single antenna- remove need for quick turnaround maintenance to avoid prohibitive data loss in event of single antenna anomaly
RF Link:
BER allocation in data capture budget
Ground station :
Data Distribution System (DDS) system provides 30 day temporary data storage; replaces Observatory recorder & eliminates complex recorder management of Observatory
Dual 30 day recorder allows for system anomalies & maintenance, as well as data storage for retransmission in event of SOC data loss or line outages
SOC data collection & analysis:
SOCs can request retransmission of science data from 30 day DDS over existing high speed data lines
Removes quick turn-around data evaluation, reducing SOC complexity and cost
NO PROCESSING OF SCIENCE DATA AT GROUND STATION
Dramatically eases complexity and cost of ground system
Allows “bent pipe” transfer of instrument science data to SOCs
Ground Station
Data Storage
HMI/AIA
Data transmission to SOCs:
High speed data lines with 1.5x capability allows for retransmission of data to SOCs from 30 day DDS storage
Result is essentially “error free’ data transmission from DDS to SOCs
Science
Community
EVE

7. SDO Ground System Architecture
10/21/03
SDO Ground System Architecture
S-Band: TRK, Cmd & HK Tlm
SDO Ground Site #2
(White Sands)
S-Band HK Tlm, TRK Data
S-Band
External
S-Band: TRK,
Tracking Station
Cmd & HK Tlm
ground system
Acquisition
(Includes 72-hr storage)
Data
Cmd
Ka-Band:
150 Mbps
Science Data
Same Interfaces
Ka-Band
as Prime Ground Site
ground system
S-Band: TRK,
(Includes 48-hr storage)
Cmd & HK Tlm
Ka-Band:
150 Mbps
Science Data
SDO Ground Site #1
SDO Mission Operations Center
(White Sands)
Observatory Commands
S-Band
Acquisition Data
ground system
Station Control
Telemetry & Command
(T&C)
System
Flight Dynamics
(Includes 72-hr storage)
System
Observatory Housekeeping Telemetry
Orbit Determination
Ka-Band
Tracking Data
Maneuver Planning
ground system
ASIST / FEDS
Station Status
Telemetry Monitoring
Product Generation
(Includes 48-hr storage)
Command Management
R/T Attitude Determination
Sensor/Actuator Calibration
Status and Control
Ka Science Data
HK Data Archival (DHDS)
HK Level-0 Processing
Mission Planning
& Scheduling
Automated Operations
Data Distribution
DDS Control
Anomaly detection
plan daily/periodic events
System
create engineering plan
(Incl. 30-Day
DDS Status
Generate Daily Loads
Science Data Storage )
Ground Station
Control System
Trending
HMI
Science Data
AIA
55Mbps
Science Data
EVE
67Mbps
Science Data
DDS
Alert Notification
System (ANS)
7 Mbps
Control System
R/T Housekeeping Telemetry
HMI AIA JSOC
(Stanford / LMSAL/
EVE SOC
R/T Housekeeping Telemetry
Palo Alto Ca.)
(LASP /
Boulder Co.)
Memory dumps
Simulated commands
Flight software loads
Simulated housekeeping telemetry
Science Planning and FDS Products
Flight Software
Maintenance Lab
(FLATSAT)
Instrument Commands / Loads

8. SDO Mission Phases Overview
Launch & Acquisition
Phase covering pre-launch configuration until Observatory is power-positive and pointing at the sun
- Launch, separation, XPNDR power on, S/A deployment & RW power, sun acquisition
In-Orbit Checkout & Orbit Circularization
Phase used during first weeks to checkout and calibrate Observatory
S/C modes verified, Ka-band deployed & verified, initial instrument checkout, calibration
Orbit circularization occurs during In-Orbit Checkout (IOC), with several burns needed at Apogee to raise orbit to GEO
Instrument Commissioning
Begins once SDO is on-station & Ka-Band downlink has been established. Phase lasts days
- Includes Instrument optical system checkout, calibration maneuvers, & commissioning activities
Science Mission Phase
Expected to be phase that mission stays in 99% of time once at GEO. Dominated by routine continuous instrument operations with few other operational activities planned
- Science data transferred first to ground, then to SOCs, all on a continual basis (24/7)
Science Mission Phase Activities/Modes
Normal Mode
Continuous routine uninterrupted instrument operations
Periodic Calibrations/ Housekeeping
Interruptions in normal science phase needed for maintaining science quality
- Instrument calibration maneuvers, Instrument alignment calibrations, HGA pointing calibration
Eclipse
Principal Observatory req in this phase is to survive & minimize impact on science operations
- Power storage and thermal (instrument optical bench and spacecraft) considerations
Stationkeeping & Momentum Management
Required operations to keep SDO within its orbit “slot” & maintain Observatory angular momentum near zero
- Planned to interrupt science once per month
Safehold & Emergency Modes
Several capabilities will exist on the Observatory for “safing” in the event of an anomaly
- Fault detection/correction, autonomous safehold, 1553 safing notification, power subsystem load shedding
Disposal
At end of mission, NASA requires disposal of SDO into an orbit that won’t interfere with other spacecraft
- Increase altitude to >300 km above GEO orbit, Passivate energy sources

9. Key Systems Engineering Functions
The Three Major Functions Must Lead to a Balanced Design that is Consistent with Project Cost, Schedule and Risk
Architecture & Design
- What the End Item looks like
- Flight and Ground Elements,
Hardware, Software Block
Diagrams, Operations Team
Special Accommodations for
Verification & Test
- Design for testability
Requirements ID & Mgmt
- Level 1 Reqs, Min Mission Reqs
-Mostly Driven by Science
- Top Down Hierarchy
- Reqs Flow, Doc Tree, WBS,
Product Structure, Team Org
Database utilized to track reqs flow,
owner, verification
Project Objectives Met,
Ready for Operations
Operations Concept Development
- How the End Item is used
-Flight and Ground Elements, Hardware, Software,
Operations Team
- How the End Item can be verified & tested on the ground
- Test Points, GSE impacts on Architecture and Design
Consistency is addressed repeatedly over the project life cycle
- Phase A brings them into initial agreement - “Single Best System”
-Major Trades performed
- Initial Reliability Analysis selects redundancy & back up approach
-Initial Performance Predictions
- Phase B refines them and shows close agreement analytically - “Right System”
- Phase C and D makes sure that they remain in agreement along with assuring design and build the “System Right”

10. SDO Requirements Flow Review
LWS Goals
LWS Goals
LWS Definition Team Report(s)
Requirements Flow
SDO Science Definition Team Report
7 Science Questions
Appendix A to the LWS Program Plan
Analysis
4 Science Objectives
AIA
EVE
Level 1 Requirements
HMI
5 Science Measurement Objectives
Science Measurement Requirements (Full and Minimum Mission)
Science
Investigation Objectives
3 Sets of Instrument Performance Reqs
(Full & Minimum Performance Reqs)
Level 2 Requirements
Mission Requirements (MRD)
Instrument and Subsystem
Requirements
Level 3 Requirements
Lower Level Requirements
Lower Level Requirements

11. 5 SDO Measurement Objectives
The following measurements are necessary to answer the seven SDO Science Questions and will be performed by the three SDO investigations:
1. Solar Cycle Measurements: Make measurements over a significant portion of the solar cycle to capture the solar variations that may exist in different time periods of a solar cycle. ALL
2. Spectral Irradiance Measurements: Measure the extreme ultraviolet spectral irradiance of the Sun at a rapid cadence. EVE
3. Dopplergrams. Measure the Doppler shifts due to oscillation velocities over the entire visible disk. HMI
4. Longitudinal & Vector Magnetic Field Measurements. Make high-resolution measurements of the longitudinal and vector magnetic field over the entire visible disk. HMI
5. Atmospheric Images. Make images of the chromosphere and inner corona at several temperatures at a rapid cadence. AIA
Each of these Measurement Objectives are identified within the Level 1 Requirements document along with Full & Minimum Mission performance levels

12. Evaluating Mission Success
SDO's success criteria for mission performance are defined in the SDO Level 1 requirements:
- FULL SUCCESS:
day intervals
Full success performance for all three investigations
Full instrument science performance requirements detailed in SDO Science Overview presentation
- MINIMUM SUCCESS:
day intervals
Minimum success performance for any two of three investigations
Minimum instrument science performance requirements detailed in SDO Science Overview presentation

13. (SDO Mission Reqs Doc [MRD], etc)
SDO Requirements Tree
Level 1
Requirements
Level 1 Reqs
(Appendix A to the LWS Program Plan)
Mission Requirements (MRD)
Cross Cutting
MAR, Elec Systems, Environment, Contamination, etc
Operations Concept Document
Level 2 Reqs
Program Data Management Plan
(SDO Science Data)
Technical Resources
(Mass, Power, etc)
(SDO Mission Reqs Doc [MRD], etc)
HMI Instrument Specification
and ICD (2 Docs)
Subsystem Requirements
Ground System Requirements
AIA Instrument Specification
and ICD (2 Docs)
Level 3 Reqs
Component Requirements
EVE Instrument Specification
and ICD (2 Docs)

14. Mission Requirements Document (MRD) Hierarchy

15. Level 1 Requirements Flow/Traceability to Level 2

16. SDO Requirements Level 1 Science Requirements
Captured in the Appendix A to LWS Program Plan
Clearly addresses the Science objectives and measurements, full and minimum mission requirements
Level 2 mission requirements captured in the Mission Requirements Document (MRD)
Level 2 requirements show clear flowdown and traceability from Level 1 Science requirements
Requirements properly and clearly allocated to specific subsystems
Detailed review process: SDO Systems Requirements Retreat (SRR), SRR/SCR, & MRD CM baseline
Other cross-cutting documents also identified as source of Level 2 requirements (MAR, Electrical Spec, Environmental Verification reqs, etc)
Derivation of Level 3 reqs as part of preliminary design & PDR preparation process
Subsystem requirements required to be submitted for CM baseline review by subsystem PDRs
Requirements show clear traceability to higher level reqs (MRD or other reqs documents)
Detailed requirements review as part of subsystem PDR process
Subsystem Level 3 requirements reviewed and baselined under CM prior to Mission PDR
Requirements status
Level 1- Ready for signature by GSFC & NASA HQ as Appendix to LWS Program Plan
Level 2- Baselined and under SDO CM
Level 3- Majority baselined and under SDO CM, remainder in CM process
ICDs- In process

17. SDO Reqs Traceability/Verification Process
All SDO requirements documents are included in the SDO document tree
All SDO requirements documents clearly identified, along with owner and due date
Traceability
Each requirements document (Level 2 and lower) includes a requirements matrix with the following fields for requirements traceability:
Requirement description and rationale
Requirements allocation (or assignment)
Requirements traceability (“Trace From”)
Provides traceability of requirements down from Level 1 through Level 2 (MRD or other cross-cutting documents) and lower
Verification
Requirements documents also include verification matrix columns alongside the reqs entries
CCR # - Documents by configuration change request any change to requirement
Verification Lead- Identifies individual or group responsible for leading and closing verification effort
Verification Status- Current status of verification effort
Verification Data- Points to data source where detailed verification information is contained
Signoff- Indicates project and systems team acceptance and signoff of verification effort
Each requirements document owner is responsible (with systems oversight) to make sure that each requirements is adequately verified and signed off as part of the systems verification process
Verification fields clearly delineate requirements signoff responsibility within documents
DOORS database used as supplementary tool to trace reqs flow and track verification
Currently continuing the process of entering Level 3 reqs into DOORs
MRD already entered into DOORS; Subsystem reqs being entered into system as they are completed and reviewed

18. SDO Environments Radiation - Total Dose and SEE Thermal
464-SYS-ANYS-0010  Radiation Analysis for the Solar Dynamics Observatory
Describes the environment, analysis method and results for the environment and preliminary Ray Trace results for certain selected areas of the Observatory
464-ELEC-SPEC-0004 Electrical Systems Specification
Documents the TID and SEE Requirements
Thermal
464-THM-REQ-0018  SDO Thermal Control Subsystem Requirements Specification
Mechanical
464-MECH-REQ-0007  Solar Dynamics Observatory (SDO) Structural Analysis and Test Requirements
Contamination
464-SYS-PLAN-0002  Solar Dynamics Observatory (SDO) Contamination Control Plan
Micrometeoroid and Orbital Debris No Special Environment Requirements
Atomic Oxygen No Special Requirements for GEO orbit or short <30 Day transfer orbit
Disturbances (Atmospheric drag, gravity gradient, solar pressure)
464-ACS-REQ-0024  SDO Attitude Control Subsystem (ACS) Requirements
Radiation - Charging Surface and Internal Requirements to mitigate ESD threats
RF Exposure Pad, Launch and Orbit RF Environment
Magnetic Orbital Environment and Observatory Generated
464-ELEC-SPEC-0004 Electrical Systems Specification
Documents the Requirements necessary to mitigate threats
464-SYS-REQ-0002  Solar Dynamics Observatory (SDO) Project Environmental Verification Requirements

19. Radiation - Total Dose and SEE
Approx 40K Rad behind 200 mil Al including 2x RDM

20. Radiation Total Dose Predictions
Radiation total dose predictions based on recent ray trace update with following assumptions
Spacecraft walls for the propulsion and spacecraft bus modules are 40 mil thick aluminum.
Spacecraft walls for the instrument module are 40 mil thick graphite composite material.
The size of the bus top deck hole is 45 inches across.
The propulsion module baseplate has 73.5 kg of mass distributed over the 10 cm thick structure
Fuel tanks are empty & have 40 mil thick titanium walls.
All boxes have 100 mil thick aluminum walls.
Doses inside each box are calculated at the center point.
The TID requirements include a 2 krad(Si) dose resulting from a top level analysis of the GTO.
The TID requirements are for the required 5-year mission in geosynchronous orbit.
The TID requirements include a factor of 2 margin.
***AIA & HMI preliminary radiation estimates shown, with TID analysis to confirm levels to be completed after PDR
CCDs are shielded with 0.6 in. (1.5 cm) Aluminum equivalent (4-pi steradians)
Optics Package electronics and Camera Electronics Boxes are shielded with 0.2 in. (0.5 cm) Al equivalent
CCDs are cooled (to approximately -75 C) to mitigate the loss of charge transfer efficiency that is caused by radiation damage
Component
Dose Requirement in Krad(Si):
ACE Box 1
6.6
ACE Box 2
7.3
AEB (AIA Elec Box)
9.1
C&DH Box 1
6.8
C&DH Box 2
7.2
Gimbal Control Box
7.6
HEB (HMI Elec Box)
IRU Box 1
7.4
IRU Box 2
6.9
IRU Box 3
Ka Transmitter Box 1
11.4
Ka Transmitter Box 2
11.3
PSE Box
8.2
S-Band XPNDR Box 1
S-Band XPNDR Box 2
EEB (EVE Elec Box)
30.8
RWs
2.7
RW Electronics Boxes
2.5
EVE Instrument
3.5 (CCDs) (ESP)
AIA Instrument ***
8 (CCDs) (Optic pkg/ Camera Elec)
HMI Instrument ***

21. Other Environments
Charging requirements (464-ELEC-SPEC-0004 Section 3.7)
External Charging: Surfaces charge then discharge to space or other parts of spacecraft
Designate Sun Side surface to bleed off charge accumulated by spacecraft portion shaded from the sun.
External surfaces (>6 cm2) shall be conductive (<109 Ohm/Sq) and grounded to the observatory structure
Unavoidable dielectrics accepted by waiver only
Solar array substrate insulator, some tape, etc
Internal Charging: Isolated conductive elements charges (floating conductors) and then discharges; Insulator charges and then discharges
Mitigated by shielding to reduce internal charge rate
Control via other methods if shielding reqs not met
Filter circuitry, exterior conductive surface coating, EMI shielding, conductive barrier, etc
Detailed in Section of Electrical Spec
No Floating conductors
Addressed in Electrical Systems portion of PDR presentation
Contamination (464-SYS-PLAN-0002)
Addressed in contamination portion of PDR presentation

22. Units Policy NASA Units Policy guidance in NASA NPD 8010.2C
“Use of the Metric System of Measurement in NASA Programs”
Adopt metric measurements as preferred system of weights and measures
Permit controlled use of hybrid units where full implementation of metric system is not feasible
Policy documented in the SEMP
Flight & Ground Operational Software use Metric units (includes Flight operational products & deliverables, such as algorithms and analysis)
Rationale: Limits opportunity for error in system with highly complex verification process; difficult to find flight units errors prior to flight; various combinations of components & parameters may not be completely exercised or tested
ICDs use metric units with English equivalent where necessary (typical for some mechanical items and Launch Vehicle)
Areas that are more easily verified via ground inspection, assembly, testing prior to flight
Manufacturing drawings can be English to enable use of US manufacturing facilities
Identify where Metric units are not used per NASA NPD C.
The plan for the prevention of misapplication of units is documented in the SEMP and implemented/tracked by the Systems Engineering team
Identify categories where units error could result in loss of mission (ICDs, drawings, analysis, models, etc)
Identify in each subsystem where units error could cause mission loss
Decide and document areas where ground verification and testing may not catch units error
Reviews, inspections, tests; Identify areas where ground testing might not catch errors where English units are misapplied
Track the defenses against misapplication of units; Correct identified potential mission critical units errors
Utilize spreadsheet or database to record and track items

23. Systems Engineering Planning
SDO Systems Engineering Management Plan acts as guiding document for System Engineering functions throughout the various mission lifecycle phases
SDO SEMP (464-SYS-PLAN-0006)
SDO SEMP Completed, reviewed by the Team and GSFC Systems Engineering Office, baselined in SDO CM system as configured document
Practical Definition of “Who” performs the Functions
Especially important to delineate responsibilities when functions are spread out among multiple partners or contracts
Describes a plan for “How” and “When” the Functions are done
“How” part should address the technique or mechanism for accomplishing the work and how various interested parties will communicate
Includes an Organization Chart with Job Description and Assignment
Details sources of communication among Observatory team
Regular meetings between system team, with project mgmt, subsystems, instruments
Website for collection/dissemination of project documents and analysis
Etc.
Includes schedule for Systems Engineering activities & the resources required.
Not intended to contain boiler plate for general Systems Engineering, but is intended to define specifics for the subject Project

24. SDO Systems Team Peer Review
SDO Systems Team Peer Review held 12/2/03
Intended as an independent review of the SDO systems engineering approach and processes by the GSFC Systems Engineering organization
Review goals and Review Team Charter:
SDO System Engineering Process
Review of the processes and approach used in the development and implementation of the SDO Mission
Are the appropriate system engineering functions clearly identified and addressed?
Are adequate processes planned to address all of the major system engineering functions required throughout the complete developmental lifecycle?
Is the implementation of system engineering functions properly identified throughout the lifecycle phases so as to guide the proper sequencing of work and catch problems and issues at an early enough stage to minimize development impacts?
Does the SDO Systems Engineering approach adequately follow the intent and guidance of GPG , Systems Engineering?
SDO System Engineering Design Implementation
Review of the SDO implementation design concept
Is there a clear flowdown of requirements to define the system and meet the mission objectives?
Does the overall implementation design reasonably balance the system requirements, architecture design, and operations concept into a cohesive whole that meets the mission objectives?
Are there any significant implementation suggestions, experience bases, or lessons-learned that could add to the SDO system implementation
Review summary and actions:
Review team pleased with the SDO implementation approach and processes
“…review team unanimously and strongly endorses both the systems engineering process and the mission design implementation that were presented at the review.”
9 RFAs generated, all in process of being addressed and closed
Systems Engineering Peer Review package, Review teams summary and comments, and RFA list available for review

25. Systems Engineering Lifecycle
SDO development effort follows the phased development approach to conceive, develop the mission implementation concept, implement, verify and test, and operate the SDO mission
Various development functions are allocated to different phases of the mission lifecycle in order to accomplish system development tasks in the proper order
The Life Cycle Phases defines the work and progression gates to the next development step
Uses schedules and milestones to guide the proper sequencing of work
The follow charts address the current phases of the Systems Engineering lifecycle by detailing the specific SDO implementation activities planned for each phase
Documented in the SDO SEMP (464-SYS-PLAN-0006, Section 3.3)
Lifecycle activities planned to be updated in the SEMP at the end of each development phase as part of planning for the next phase

26. SDO Phase B Activities System Definition - Phase B Status
Understanding the Objectives
- Level 1 Science Reqs competed & signed off by NASA HQ; Includes minimum mission reqs
- Track any changes to Level 1 reqs (changes req NASA HQ approval)
- Level 1 reqs updated & incorporated in Appendix to LWS Program Plan & ready for signoff
Operations Concept Development
- Refine SDO Mission Phases definitions and SDO Operation Concept Document
- Mission Phases updated & Mission timeline added; SDO Ops Concept Document baselined under SDO CM
Architecture & Design Development
- CM block diagram of SDO architecture design concept
- Begin preliminary system and subsystem design process
- Begin conceptual breadboard design process; use conceptual breadboards as initial testbeds and for initial interface testing across subsystems for risk reduction
- Prelim Architecture baselined by various subsystem specs; preliminary design process underway; BBs in process for functional design verification
Requirements Identification & Management
- Define draft Level 2 MRD reqs & demonstrate flowdown & traceability to Level 1 reqs at MDR
- Detailed walkthrough of MRD Level 2 reqs traceability and assignment at SRR
- Initial entry of MRD Level 2 reqs into DOORS database for mgmt and tracking
- Define initial SDO Doc Tree, detailing subsystem reqs documentation structure & responsibility
- MRD reviewed and baselined, entered into DOORS for reqs management & tracking; SDO document tree updated with SDO core documents and allocations
Validation & Verification
- Update MRD Level 2 reqs with verification information and use process to check validity of reqs
- Preliminary verification information incorporated into MRD; Reqs validation via Peer & PDR reviews, DOORS entry started, verification matrix baselined or in process
Interfaces & ICDs
- Baseline and release initial documents and ICDs on SDO Document Tree
- MRD, Subsystem Level 3 reqs baselined; ICD’s in process
Mission Environments
- Complete more detailed radiation environment assessment and Observatory ray trace
- Update contamination assessment and complete draft Contamination Control Plan
- Begin evaluation and tracking of parts and materials for use in identified flight environment
- Update flight operational & test environments in Systems Verif & Envi Def document
Environments identified and documented
SDO Verif and Envi Reqs Doc baselined
Ray trace updated
Contamination assessment completed (Contam PDR)
Parts ID, evaluation, & tracking
Technical Resource Budget Tracking
- Bring resource allocations under CM at beginning of Phase B within appropriate margins
- Track and control resource allocations to complete Phase B within PDR margin allocations
SDO technical resources under CM control
All technical resources within PDR margin allocations
Risk Management
- Complete initial FMEA of preliminary design concept and fold results back into design
- Update fault tree analysis and reliability block diagrams & use to further optimize design concept
- Ongoing identification, classification, & reporting of risk items per Risk Mgmt Plan & Procedures
Prelim reliability studies completed for each subsystem as part of Subsystem PDR process
Risk Mgmt process ongoing per Risk Mgmt Plan
System Milestone Reviews
- Hold subsystem peer reviews and PDRs to review Level 1 reqs and initial design concepts
- Hold PDR for external review team- acts as review milestone for progression Phase C
- Subsystem PDR held- PDR packages available
Configuration Management & Documentation
- Initiate CCB process to address changes to configured documents
- Bring Level 1 Reqs, MRD Level 2 Reqs, and Level 3 Subsystem spec under CM
- MRD, Other Level 2 Docs, Level 3 Reqs docs brought under CM
System Engineering Management Plan
- Update SEMP for Phase C Design activity plans to ensure system is “implemented right”
- SEMP updated and baselined for entry into Phase C

27. SDO Phase C Activities System Design Phase C
Understanding the Objectives
- Track any changes to Level 1 reqs (changes req NASA HQ approval)
Operations Concept Development
- Complete SDO Mission Phases definitions and SDO Operation Concept Document and bring document under CM
Architecture & Design Development
- Begin ETU design process; use ETU for design validation and for initial interface testing across subsystems for risk reduction
Requirements Identification & Management
- Track changes to Level 2 MRD and Level 3 reqs using DOORS database for reqs mgmt
Validation & Verification
- Begin effort to verify all reqs that identify analysis as verification method
- Begin formulation, development and planning for Comprehensive Performance Test (CPT), used to validate reqs and system functionality and performance
Interfaces & ICDs
- Baseline and release component and lower level ICDs
Mission Environments
- Update and maintain environmental assessments and plans
- Continue evaluation and tracking of parts and materials for use in identified flight environment
- Update flight operational & test environments in Systems Verif & Envi Def document for use in subsystem and Observatory verification program
Technical Resource Budget Tracking
- Track and control resource allocations to complete Phase C within CDR margin allocations
Risk Management
- Complete initial FMEA of flight design concept and assess results
- Update fault tree analysis and reliability block diagrams & use to evaluate design concept
- Ongoing identification, classification, & reporting of risk items per Risk Mgmt Plan & Procedures
System Milestone Reviews
- Hold subsystem CDRs to review flight design concepts
- Hold CDR for external review team- acts as review milestone for progression Phase D
Configuration Management & Documentation
- Bring flight drawings and ICDs under CM
System Engineering Management Plan
- Update SEMP for Phase D Development activity plans to ensure flight system is properly tested and verified

28. SDO SRR/SCR SDO SRR/ SCR held April 8-11 2003 SRR/SCR RFA status:
Objectives
Demonstrate that the system requirements are clearly defined and reflect mission objectives
Demonstrate that the Mission architecture/design/operations concept is acceptable
i.e. system fulfills mission objectives and can be built within the project constraints
Demonstrate that a preliminary development flow and preliminary product verification program are defined
Demonstrate mission requirements, architecture/design, and operations concept is developed and documented at a level sufficient to proceed into preliminary design
SRR/SCR RFA status:
Received 54 RFAs
Status as of PDR presentation submission deadline
51 dispositioned by SDO team and submitted for closure review by Code 300 & Independent Review teams
34 closed by Code 300 Review Chair
17 still remain open pending closure review by Code 300 Review Chair
3 remain open

29. Open SDO SCR RFAs
The following SCR RFAs were still open as of the PDR presentation deadline submission date
Formal responses for each of these RFAs are available as parts of SCR RFA status package
SCR RFA #19 Document Launch Window Constraints
SCR RFA #43 Evaluate heat rise in MMIC to avoid Tjunc above 125C; consider alternate design configurations
SCR RFA #53 Examine and define reliability triggers for end of life disposal

30. Mission Systems Summary
Reviews of system and subsystem requirements, designs, and operations concept are mutually consistent and contain sufficient detail/ maturity to proceed with detailed design activities
Requirements clearly allocated and flow-down to the subsystem level shown, as well as traceability to higher-level reqs
Design concept meets functional and performance requirements based operations concept (both system and subsystem level)
Architecture trades of various implementation concepts as well as those considered to enhance mission reliability have been completed and documented
Project and review team review of subsystems requirements, designs, and implementation concepts (Reqs baseline process, Peer reviews, Subsystem PDRs, etc.)
Project drivers and risks are clearly identified and tracked as part of ongoing SDO process
Sufficient detail in the preliminary design to support cost and schedule estimates for phases C, D, & E
Technical resources and budgets have been established, are clearly allocated and within acceptable margins
Plan for implementation of Phases C, D, E are clearly laid out in the Systems Engineering Management Plan
Ready to proceed into the detailed design phase