320 likes | 570 Views
Mission Systems Overview. John Ruffa SDO Mission Systems Engineer. 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
E N D
Mission Systems Overview John Ruffa SDO Mission Systems Engineer
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
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
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
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
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
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 External S-Band S-Band: TRK, Tracking Station Acquisition ground system Cmd & HK Tlm Data (Includes 72-hr storage) Cmd Same Interfaces Ka-Band: 150 Mbps Science Data Ka-Band as Prime Ground Site ground system (Includes 48-hr storage) S-Band: TRK, Cmd & HK Tlm Ka-Band: 150 Mbps Science Data SDO Ground Site #1 SDO Mission Operations Center Observatory Commands (White Sands) Acquisition Data S-Band Flight Dynamics ground system Telemetry & Command (T&C) System Station Control System (Includes 72-hr storage) Observatory Housekeeping Telemetry Orbit Determination Ka-Band Tracking Data Maneuver Planning ASIST / FEDS ground system Product Generation Telemetry Monitoring Station Status R/T Attitude Determination (Includes 48-hr storage) Command Management Sensor/Actuator Calibration HK Data Archival (DHDS) Status and Control Ka Science Data HK Level-0 Processing Mission Planning & Scheduling Automated Operations Data Distribution DDS Control plan daily/periodic events Anomaly detection create engineering plan System DDS Status Generate Daily Loads (Incl. 30-Day ) Science Data Storage Ground Station Trending Control System HMI Science Data AIA EVE 55Mbps Science Data Science Data Alert Notification System (ANS) DDS 67Mbps 7 Mbps Control System R/T Housekeeping Telemetry HMI AIA JSOC (Stanford / LMSAL/ R/T Housekeeping Telemetry EVE SOC 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
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”
SDO Requirements Flow Review • LWS Goals • LWS Goals LWS Definition Team Report(s) Requirements Flow SDO Science Definition Team Report Appendix A to the LWS Program Plan • 7 Science Questions Analysis • 4 Science Objectives AIA Level 1 Requirements EVE • 5 Science Measurement Objectives HMI • 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
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
Evaluating Mission Success • SDO's success criteria for mission performance are defined in the SDO Level 1 requirements: • - FULL SUCCESS: • 22 72-day intervals • Full success performance for all three investigations • Full instrument science performance requirements detailed in SDO Science Overview presentation • - MINIMUM SUCCESS: • 11 72-day intervals • Minimum success performance for any two of three investigations • Minimum instrument science performance requirements detailed in SDO Science Overview presentation
Level 1 Reqs Level 3 Reqs Level 2 Reqs Subsystem Requirements Component Requirements HMI Instrument Specification and ICD (2 Docs) AIA Instrument Specification and ICD (2 Docs) EVE Instrument Specification and ICD (2 Docs) SDO Requirements Tree Level 1 Requirements (Appendix A to the LWS Program Plan) Mission Requirements (MRD) Operations Concept Document Cross Cutting MAR, Elec Systems, Environment, Contamination, etc Technical Resources (Mass, Power, etc) Program Data Management Plan (SDO Science Data) (SDO Mission Reqs Doc [MRD], etc) Ground System Requirements
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
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
SDO Environments • Radiation - Total Dose and SEE 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
Radiation - Total Dose and SEE Approx 40K Rad behind 200 mil Al including 2x RDM
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
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 3.7.3 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
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 8010.2C. • 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
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
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 7120.5, 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
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
SDO SRR/SCR • SDO SRR/ SCR held April 8-11 2003 • 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
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
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