Post on 16-Oct-2020
Systems Requirements Review- 1 2/8/2015
1
Science Overview Vassilis Angelopoulos
University of California, Los Angeles
Systems Requirements Review- 2 2/8/2015
Space Weather Not Well Understood
Systems Requirements Review- 3 2/8/2015
RADIATION BELTS: DISCOVERED IN 1958, STILL MYSTERIOUS
Explorer 1, 1958
Time Magazine, May 4, 1959
Systems Requirements Review- 4 2/8/2015
EXECUTIVE OVERVIEW • The Challenge
– Geospace storms result in relativistic electron flux increases only half of the time – unclear why. – Electron fluxes result from competition of acceleration, transport and loss. The first two processes are
measured well by many equatorial, high altitude NASA, NOAA and DOE missions, but not loss • Goal
– To advance our understanding of dominant wave-loss mechanism of relativistic “killer” electrons.
• Approach – Measure, for the first time, if the angle
and energy distribution of precipitating electrons bear the characteristic signature of scattering by the dominant wave scatterer, Electromagnetic Ion Cyclotron (EMIC) waves
• Science Closure – ELFIN will compare the measured loss rates and electron properties during storms with theoretical
models from EMIC wave scattering and from other mechanisms. – Storm recurrence once-per-month in the declining phase of solar cycle 3 mo. minimum mission.
Systems Requirements Review- 5 2/8/2015
Determine location of ionospheric space current sources relative to tail boundaries (dipole vs. tail; inner edge of plasma sheet vs. its boundary).
SECONDARY SCIENCE OBJECTIVE
Systems Requirements Review- 6 2/8/2015
SCIENCE OBJECTIVES
Objective ID Title Objective
Primary OBJ-01 Radiation Belt Loss Sources
Determine whether EMIC scattering is the primary loss mechanism of radiation belt “killer electrons”, or if other mechanisms are also important during the course of one storm.
Secondary OBJ-02 Origin of Field-aligned Currents
Determine location of FAC sources relative to plasma boundaries (dipole vs. tail; inner edge of plasma sheet vs. plasma sheet boundary)
Systems Requirements Review- 7 2/8/2015
SCIENCE REQUIREMENTS REQ ID Requirement Rationale Parent(s)
Primary
SCI-01 ELFIN shall measure the storm-time electron pitch angle distribution within the loss cone
Pitch angle distributions as a function of time at fixed energy provide a signature that can be used to determine whether 0.5 – 4 MeV electrons are scattered by EMIC waves
OBJ-01
SCI-02 ELFIN shall measure the storm-time electron energy spectrum within the loss cone
Energy spectra at fixed pitch angles can be used to determine the minimum resonant energy of precipitating electrons for comparison with EMIC waves
OBJ-01, OBJ-05
SCI-06
ELFIN shall measure the full angle/energy spectrum at every ΔL=0.5 from L=3 to L=5 (minimum) or ΔL=0.25 from L=2 to L=9 (baseline) once per orbit
Needed to determine if EMIC scattering is a dominant loss mechanism of relativistic electrons during geomagnetic storms OBJ-01
Secondary
SCI-03 ELFIN shall measure the storm-time ion energy spectrum within the loss cone
Observations of ions within the loss cone can be used to identify the isotropy boundary
OBJ-02, OBJ-03
SCI-04 ELFIN shall measure the perpendicular and parallel components of the storm-time ion pitch angle distribution within the loss cone
Perpendicular and parallel components of the ion pitch angle distribution provide a signature that can be used to determine the isotropy boundary
OBJ-02, OBJ-03
SCI-05 ELFIN shall be capable of measuring magnetic field perturbations with a frequency of at least 2 Hz
Needed to measure the expected EMIC waves
OBJ-02, OBJ-04
Systems Requirements Review- 8 2/8/2015
ELFIN Implementation Strategy Polar orbit (>70°), on any initial MLT (except sun-synchronous at ±1hr from noon-midnight) Full angular distribution of electrons (100keV-4MeV) measured by EPD instrument Spin-axis ~ orbit-⊥ (for stability) and B-field-⊥ (allows full pitch angle coverage by EPD) Magnetic torque coils adjust spin-axis attitude EMIC waves and B field measured by FGM instrument
ELFIN Operations and Data Use Two Earth Stations (UCLA, WPI) Experimental on Amateur bands for communication Latency: < 1day including L0-L2 processing. Get >1 auroral/rad.belt crossing per 4 orbits (6 hrs). Record on-board multiple crossings, survey and
select the ones to downlink later Open data policy, common data tools (SPEDAS)
Complements many other missions Scientific: VAP and THEMIS (HEO) [NASA]; ERG (HEO) [JAXA]; DSX (MEO), VPM
(LEO) [DOD]; ACE, WIND, DISCVR (L1) Operational: DMSP (LEO), GPS (MEO) [DOD]; LANL (HEO) [DOE]; POES (LEO), GOES
(HEO) [NOAA]
MISSION OVERVIEW
Systems Requirements Review- 9 2/8/2015
12 - 24+/- 1hr LT: Reduced science (EMIC waves not often there)
12
6
18
13-1 hr LT: Worst case power: science ON and low power input.
12
6
18
6-18 hr LT: Best case power: science ON and high power input.
12
6
18
MISSION OVERVIEW
12 12 12
18 9
24 24 24
Systems Requirements Review- 10 2/8/2015
11/2008: ELFIN chosen as the top UCLA CubeSat concept 11/2009: proposed to NSF to piggyback the ELFIN instruments
on the MSU Lomonosov mission (PI: Shprits) won: 3/2010; delivered: 7/2011; launch: 2015+
Proposed to AFOSR/UNP NS8 for (small) funding (2012). Selected: 12/2012. Training, reviews by AFRL continue.
11/2013 proposed for “ELaNa” ride; won (#3/15): 2/2014 Identified launch opportunity. Potential launch in 11/2016.
Submitted to: NSF (2012) and NASA (2013). Jointly selected: 7/16/2014. UCLA executed award: 9/28/2014
PROGRAM BACKGROUND
Systems Requirements Review- 11 2/8/2015
ELFIN’s Systems Engineering Processes
Shin Yamamoto
Systems Requirements Review- 12 2/8/2015
Name Responsibility
Eric Grimes Mentor
Shin Yamamoto Co-Lead
Jeff Asher Co-Lead
Anais Zarifian Budgets
John Hayes Requirements
Prescott Rynewicz Payload ICD
SYSTEMS ENGINEERING TEAM OVERVIEW
Systems Requirements Review- 13 2/8/2015
ELFIN’s Systems Engineering Team works on
Requirements management and V&V
Resource management
Interface management
Project document lists
Technical evaluations
SYSTEMS ENGINEERING MANAGEMENT
Systems Requirements Review- 14 2/8/2015
Requirements management includes Organizing requirements from level 1 to level 4 Documenting the traceability of all requirements in the
MRD Managing the process of changing requirements after they
are frozen Requirements verification and validation includes
Verification methods Inspection Analysis Test Demonstration
Validation Ensuring the performance of the spacecraft
REQUIREMENTS MANAGEMENT AND V&V
Systems Requirements Review- 15 2/8/2015
Level 1 (Drivers) Level 2 (Mission) Level 3 (System) Level 4 (Subsystem)
REQUIREMENTS MANAGEMENT AND VERIFICATION
Science Requirements
Resource Constraints
Budget, schedule, etc
Spacecraft Ground System
Mission Design
Lifetime, orbit, etc
Environment Radiation, thermal,
etc
Operations Science, Mission Earth Stations
FGM EPD-e
EPD-i IDPU
C&DH
Thermal ADCS
Struct Power
Comm
Testing Functional,
performance, etc
Contractual Requirements
Systems Requirements Review- 16 2/8/2015
Instrument performance requirements derived directly from Level 1 science requirements
Component, assembly and part level requirements are responsibilities of the subsystem lead
Between UNP and CubeSat specification requirements, the more conservative ones are chosen to qualify for a wider range of launch vehicles
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 17 2/8/2015
SCI-01: ELFIN shall measure the storm-time electron pitch angle distribution within the loss cone
MSN-08: ELFIN shall maintain its spin plane to within ≤ 15˚
of the local B-field in the magnetic latitude range 60-65 degrees
ADCS-02: The ADC subsystem shall be capable of ±5 degrees
of attitude control ADCS-03: The ADC subsystem shall be capable of ±3 degrees
of attitude knowledge
Requirements flowdown example:
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 18 2/8/2015
An MRD is used to organize the flowdown traceability of every requirement
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 19 2/8/2015
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 20 2/8/2015
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 21 2/8/2015
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 22 2/8/2015
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 23 2/8/2015
Verification Method Inspection
Inspect the development of ELFIN to ensure the cubesat specification
Analysis Run computer simulations to analyze the factor of safety
Test Conduct environmental testing for flight configurations
Demonstration Stacer boom deployment is previously demonstrated in a
different mission
Verification of requirements will be conducted at both systems and subsystem levels
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 24 2/8/2015
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 25 2/8/2015
REQUIREMENTS MANAGEMENT AND VERIFICATION
Level 1 & Level 2 requirements frozen after RFAs are closed from Science Requirements Review
Level 3 & Level 4 requirements frozen after RFAs are closed from Systems Requirements Review
After requirements are frozen, changes need approval from: Level 1 & Level 2: PI, Configuration Control Board Level 3 & Level 4: Configuration Control Board, affected
subsystem leads
Configuration Control Board: Project Manager (student), Chris Shaffer Chief Engineer (mentor), Ryan Caron Chief Engineer (student), Michael Anderson Systems Engineer (mentor), Eric Grimes Systems Engineer (student), John Hayes
Systems Requirements Review- 26 2/8/2015
Process of changing requirements Meet and establish a plan Check for traceability with parent
requirements Define a verification method Inspection Analysis Demonstration Test
Communicate with affected subsystems
REQUIREMENTS MANAGEMENT AND VERIFICATION
Systems Requirements Review- 27 2/8/2015
Budget Owner Team
Mass, Pointing Anais Zarifian Systems
Power Shin Yamamoto Systems
Link Kyle Colton Communications
Data Lydia Bingley Operations
RESOURCE MANAGEMENT
Systems Requirements Review- 28 2/8/2015
Margin Percentage Early Concept 25 Mockup 20 Prototype 15 Development Model 10 Engineering Model 7 Flight Model 5
Limitations by CubeSat specifications minimizes the allowable margin applied in our budgets
Below is our margin criteria
RESOURCE MANAGEMENT
Systems Requirements Review- 29 2/8/2015
To manage our interface requirements, we follow
the agreements in
Interface Control Documents (ICD)
Mechanical ICD for the entire spacecraft
Electrical and Data ICD by subsystem
N-Squared Diagram
Functional Block Diagram
INTERFACE MANAGEMENT
Systems Requirements Review- 30 2/8/2015
INTERFACE MANAGEMENT
Systems Requirements Review- 31 2/8/2015
INTERFACE MANAGEMENT
Systems Requirements Review- 32 2/8/2015
Documentation of various lists
PROJECT DOCUMENT LISTS
Lists Owner Team
Engineering Document List
Anais Zarifian Systems
Master Equipment Anais Zarifian Systems
Materials Jeff Asher Systems
Cables Shin Yamamoto Systems
Test Procedures Michael Anderson Chief Engineer
Trade Studies Michael Anderson Chief Engineer
Systems Requirements Review- 33 2/8/2015
ENGINEERING DOCUMENT LIST
Systems Requirements Review- 34 2/8/2015
MASTER EQUIPMENT LIST
Systems Requirements Review- 35 2/8/2015
MATERIALS LIST
Systems Requirements Review- 36 2/8/2015
CABLES LIST
Systems Requirements Review- 37 2/8/2015
Technical evaluations are executed in order to Establish the progress of the project Identify problems in the project Communicate technical status to the Project Management
Benefits to multiple, continuous, and accurate evaluations include Identifying issues Discovering trade studies Developing solutions
Technical evaluations are divided into two categories Peer Reviews Project Reviews
TECHNICAL EVALUATION
Systems Requirements Review- 38 2/8/2015
Project Reviews
Science Requirements Review (July 31, 2014)
Systems Requirements Review (February 8, 2015)
Preliminary Design Review (February 12, 2015)
Critical Design Review
Pre-Environmental Review
Mission Operations Review
Pre-Ship Review
Mission Readiness Review
TECHNICAL EVALUATION
Systems Requirements Review- 39 2/8/2015
Science Requirements Review (SciRR) A technical review of the top-level science objectives and
their flow down to science and mission and instrument requirements
Systems Requirements Review (SRR) A technical review of the mission requirements at the
system level, in order to demonstrate that the system level requirements convene with the mission objectives, and that the system specifications are satisfactory to meet the project objectives.
Preliminary Design Review (PDR) A technical review of the preliminary design showing that it
meets requirements with an acceptable risk, that the design is adequately defined, and that it can be verified.
TECHNICAL EVALUATION
Systems Requirements Review- 40 2/8/2015
Critical Design Review (CDR) A technical review of the complete system design in full
detail, showing that all problems have been resolved, and that the design is sufficiently mature to proceed to testing.
Pre-Environmental Review (PER) A formal technical review of the System that establishes
functional compliance with all technical requirements prior to exposure to environmental testing.
Mission Operations Review (MOR) A formal review to determine the state of readiness of the
Ground Segment to support the System operations functions.
TECHNICAL EVALUATION
Systems Requirements Review- 41 2/8/2015
Pre-Ship Review (PSR) A technical and programmatic review prior to shipment of
the Space Segment to the launch site to demonstrate the System has verified all the requirements. The technical review will concentrate on the past system performance during functional and environmental testing. The programmatic review will emphasize preflight activities planned for the launch site and other support areas.
Mission Readiness Review (MRR) A formal review to determine the overall readiness of the
system for Launch.
TECHNICAL EVALUATION
Systems Requirements Review- 42 2/8/2015
Questions?
SYSTEMS ENGINEERING
Systems Requirements Review- 43 2/8/2015
MISSION REQUIREMENTS
Mission Requirements
John
Systems Requirements Review- 44 2/8/2015
MISSION REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
MSN-01 There shall be no RF transmission for the first 45 minutes after separation from the launch vehicle
Constraint levied by the launch service provider to protect the primary payload
CubeSat Design Specification Rev. 13 (3.4.5)
I/A: Verified at lower level; see flow-down verification
MSN-02 There shall be no deployable actuation during the first 30 minutes after separation from the launch vehicle
Constraint levied by the launch service provider to protect the primary payload
CubeSat Design Specification Rev. 13 (3.4.4)
I/A: Verified at lower level; see flow-down verification
MSN-03 ELFIN shall deorbit within 25 years from the conclusion of the mission
Constraint levied by government regulations to prevent “space junk”
CubeSat Design Specification Rev. 13 (3.4.3)
A: Analysis documented by ODAR
MSN-11 ELFIN shall conform to the Poly Picosatellite Orbital Deployer (P-POD) deployment system
Programmatic constraint needed to get a launch
CubeSat Design Specification Rev. 13
I/A: Verified at lower level; see flow-down verification
Systems Requirements Review- 45 2/8/2015
MISSION REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
MSN-14 ELFIN's apogee and perigee shall conform to the ELFIN orbits chart
Constraint on the orbits we can accept set by environmental and deorbit constraints; ensures the spacecraft is designed to survive the space environment of low earth orbit
SCI-01, SCI-02, SCI-03, SCI-04
I: Inspection of Launch Documents
MSN-06 ELFIN shall have an orbit inclination greater than 70˚
Ensures ELFIN doesn’t miss the upper limits of the radiation belt every orbit
SCI-01, SCI-02, SCI-03, SCI-04
I: Inspection of Launch Documents
MSN-07 ELFIN shall take measurements for 6 months nominal (baseline) and no less than 3 months (minimum)
Derived requirement - assuming 1 storm per month nominal cadence
SCI-01, SCI-02, SCI-03, SCI-04
I/A: Verified at lower level; see flow-down verification
MSN-08
Spin plane shall be within ≤ 15˚ of the local B-field in the magnetic latitude range 60-65 degrees at least once every 6 hours
Needed to measure pitch angle distributions within the outer radiation belt
SCI-01, SCI-04 A: Attitude determination/ calculations
Systems Requirements Review- 46 2/8/2015
MISSION REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
MSN-09 ELFIN shall have a spin rate between 10 and 30 rpm
Upper limit avoids low count rates; lower limit avoids aliasing in L-shell
SCI-01, SCI-04
I: In-orbit Inspection/Verified at lower level; see flow-down verification
MSN-10 ELFIN shall be capable of maintaining a spin rate precision of ±2 rpm
Attitude control needed to resolve pitch angle distributions
SCI-01 I/A: Verified at lower level; see flow-down verification
MSN-12
ELFIN subsystems shall be capable of surviving worst-case environmental conditions for nominal science operations
Ensure ELFIN's survival in worst-case environmental conditions
SCI-01, SCI-02, SCI-03, SCI-04
I/A: Verified at lower level; see flow-down verification
MSN-13 ELFIN shall take measurements at least once every 6 hours
Ensures nominal science measurements are met SCI-06 I/A: Verified at lower level;
see flow-down verification
Systems Requirements Review- 47 2/8/2015
MISSION REQUIREMENTS REQ ID Requirement Rationale Parent(s) Verification
Method
MSN-14 ELFIN shall have the orbit has indicated in graph 'X‘ (next slide)
Constraint on the orbits we can accept set by environmental and deorbit constraints; ensures the spacecraft is designed to survive the space environment of low earth orbit
SCI-01, SCI-02, SCI-03, SCI-04
I: Inspection of Launch Documents
Systems Requirements Review- 48 2/8/2015
MISSION REQUIREMENTS
400
500
600
700
800
900
1000
1100
1200
1300
300 400 500 600
Apo
gee
alt [
km]
Perigee alt [km]
ELFIN orbit requirements 70º inclination, 4.0 kg, 400 cm² (magnetometer deployed), Cd 2.4
Technical capability refers to bus limitations (radiation, thermal, communications)
Deorbit 12 yr
Deorbit 25 yr
Technical capability Deorbit 2 yr
Deorbit 1 yr
Systems Requirements Review- 49 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-01 ELFIN shall undergo environmental testing in a flight configuration
Conservative estimates for launch conditions
MSN-11 T: Environmental testing.
SYS-02
ELFIN shall be designed to withstand the launch and on-orbit environments of the launch vehicle without failure, leaking fluids, or releasing anything.
Conservative estimates for launch conditions
MSN-11 A/T: Vibration, Thermal, and Static Simulations/Tests
SYS-03
ELFIN shall be designed to withstand the loads given by the Mass Acceleration Curve from the Titan IV as shown in NS8 Users Guide Figure 7.
Conservative estimates for launch conditions
MSN-11 A: Statics simulation
SYS-04
Factors of safety to be used are 2.0 for yield and 2.6 for ultimate for structural design and analysis. Factor of Safety for mechanism loads are 1.0 for test and 2.0 for analysis for operating torque margin and holding torque margin.
Conservative estimates for launch conditions
MSN-11 A: Solidworks simulation
Systems Requirements Review- 50 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-05 The CubeSat shall be designed to accommodate ascent venting per ventable volume/area < 2000 inches.
Conservative estimates for launch conditions
MSN-11 T: Testing in UCLA thermal vacuum chamber.
SYS-06
ELFIN shall be designed to withstand the loads given by the Mass Acceleration Curve from the Titan IV as shown in NS8 Users Guide Figure 7.
Conservative estimates for launch conditions
MSN-11 T/A: Shock and Vibration Simulations
SYS-07 ELFIN flight hardware shall be maintained in at least a Class 100,000 level facility.
To protect flight hardware for particle contaminants
MSN-11 I: Routine inspection of flight hardware per Contamination Control Plan
SYS-08 All ELFIN flight hardware shall be maintained at the Visibly Clean level, per KSC-C-123H
Prevent damage to hardware MSN-11
I: Inspection of all flight hardware prior to, during and after use.
Systems Requirements Review- 51 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-09 CubeSat hazardous materials shall conform to AFSPCMAN 91-710, Volume 3.
Constraint levied by government regulations
MSN-11/CubeSat Design Specification Rev. 13 (3.1.7)
I: Inspection of Development Model
SYS-10
Use of non-metallic material shall be restricted to materials that have a maximum collectable volatile condensable material (CVCM) content of 0.1% or less and a total mass loss (TML) of 1.0% or less.
Prevent damage to hardware due to outgassing
MSN-11/CubeSat Design Specification Rev. 13 (3.1.8)
I/T: Design and vacuum testing
SYS-11
ELFIN shall use no materials with a melting point high enough to allow a sample to reach the earth with greater than 15 joules of energy.
Constraint levied by government regulations
CubeSat Design Specification Rev. 13 (3.3.4)
A: De-Orbit Simulation
SYS-12
ELFIN shall be designed for EMC and for mitigation of EMI, specifically susceptibility to launch vehicle and range radiation environments.
Flow-down MSN-12 T: Testing in UCLA Mag Chamber
Systems Requirements Review- 52 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-13
Operator controls shall not be considered a design inhibit. Operator controls are considered a control of an inhibit. (i.e. inhibits are electrical and/or mechanical hardware)
Constraint levied by the launch service provider to protect the primary payload
MSN-11 I: Inspection of Development, Engineering, and Flight Model
SYS-14 As a 3U CubeSat, ELFIN shall not exceed 4.0 kg mass.
Required for ELFIN to be considered a 3U+ CubeSat
CubeSat Design Specification Rev. 13 (3.2.12)
I: Inspection of Engineering and Flight Model
SYS-15
ELFIN shall be designed to withstand the launch vehicle 0.05 G^2/Hz vibroacoustic environment, as detailed in Table XIII and Figure 11 of UNP-NS8-Userguide_IR, without failure.
Conservative estimates for launch conditions
MSN-11 I: Inspection of Development, Engineering, and Flight Model
SYS-16 ELFIN shall use materials that comply with NASA-STD-6016
Constraint levied by government regulations
NASA-STD-6016 I: Inspection of Engineering and Flight Model
Systems Requirements Review- 53 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-18 All components shall not exceed 6.5 mm normal to the surface of the 100.0 mm cross-section
Required for ELFIN to be considered a 3U+ CubeSat
CubeSat Design Specification Rev. 13 (3.2.3)
I: Inspection of Engineering and Flight Model
SYS-19 Exterior components on ELFIN shall not contact the interior surface of the P-POD, other than the designated CubeSat rails.
Flow-down MSN-11 I: Inspection of Engineering and Flight Model
SYS-21 The spacecraft shall be complacent with the magnetic cleanliness plan Flow-down SCI-05 T: Testing in UCLA in house
magnetic testing facility.
SYS-22 No component or subsystem shall exceed the power allocated in the ELFIN system power budget
Ensures the limiting power constraint is met with margin
T/A: Measured power consumption data during component tests
Systems Requirements Review- 54 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-23 All ELFIN elements shall be compatible per their ICDs
Ensures interface requirements are satisfied
T: Element Testing
SYS-24 ELFIN shall not generate electromagnetic interference at or near 8000 Hz
EMI susceptibility of FGM at 8000 Hz MSN-13 T: Testing in UCLA in-house
facility
SYS-26 The electrical inhibits topology shall conform to the inhibit requirements as laid out in NSTS1700.7B.
Levied by launch service provider MSN-11 I: Inspection of Development,
Engineering, and Flight Model
SYS-27 ELFIN shall be capable of nominal operations during eclipse intervals Flow-down MSN-12 A/T: Simulations and Dark
Room Testing
Systems Requirements Review- 55 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-28 ELFIN shall be capable of operating in a reduced science mode with one operational battery
Flow-down MSN-12 I/T: Inspection of schematics and Power Board Testing
SYS-29 The ELFIN bus subsystems shall survive the temperature ranges provided in the Thermal ICD
Ensure ELFIN's survival in worst-case thermal conditions
MSN-12 A/T: Thermal analysis; Verified during Thermal Vacuum Testing
SYS-30 The ELFIN bus subsystems shall perform as designed within the temperature ranges provided in the Thermal ICD
Provides thermal limits for component design
MSN-12 A/T: Thermal analysis; Verified during Thermal Vacuum Testing
SYS-31 The bus subsystems shall be able to turn on at the minimum temperature provided in the Thermal ICD.
Provides thermal limits for component design
MSN-12 A/T: Thermal analysis; Verified during Thermal Vacuum Testing
Systems Requirements Review- 56 2/8/2015
SYSTEM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
SYS-32 ELFIN flight model shall not be exposed to magnetic fields larger than 50 Gauss
To prevent damage to the FGM I: Inspection of Launch
Procedures
SYS-33 ELFIN shall be able to be charged while inhibited Waived
SYS-34 The spacecraft shall be compliant with the contamination control plan
Minimize damage to components
I: Inspection of components and facility
Systems Requirements Review- 57 2/8/2015
FGM REQUIREMENTS
FGM Requirements
Kathryn
Systems Requirements Review- 58 2/8/2015
FGM REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-21 The FGM shall have a range of 55,000 nT Earth's field is expected to be TBD
SCI-01, SCI-04, SCI-05
T: Verified during instrument calibration
PLD-22 The FGM shall have a resolution of 0.1 nT Sufficient Precision required by Science
SCI-01, SCI-04, SCI-05 I: by design
PLD-23 The FGM shall have an absolute stability of 100 nT Stability required by Science
SCI-01, SCI-04, SCI-05
T: Verified during instrument calibration
PLD-24 The FGM shall have a relative stability of 1 nT/2 hr Stability required by Science
SCI-01, SCI-04, SCI-05
T: Verified during instrument calibration
PLD-25 The FGM shall have a noise level of 0.5 nT/sqrt(Hz) Noise level required by Sciece
SCI-01, SCI-04, SCI-05
T: Verified during instrument calibration
PLD-27 The FGM shall have a digitization of > 20 bits Resolution required by Science
SCI-01, SCI-04, SCI-05 I: by design
PLD-28 The orthogonality of the FGM sensor shall be known to <= 5 degrees
Needed to find the pitch angle distribution
SCI-01, SCI-04, SCI-05
T: Verified during instrument calibration
PLD-29 The FGM sampling rate shall exceed DC-5Hz Needed to find EMIC waves which are 1-2Hz
SCI-01, SCI-04, SCI-05 I: by design
Systems Requirements Review- 59 2/8/2015
EPD REQUIREMENTS
EPD Requirements
Maxwell Chung
Systems Requirements Review- 60 2/8/2015
DETECTOR STACK DESIGN EPD-E
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-07 The EPD-E shall be capable of rejecting ions less than 500 keV
Want to reject ions from EPD-E SRIM, TRIM, and CASINO simulations
PLD-09 The EPD-E shall be able to measure electrons with an energy range of 0.5 to 4 MeV
Primary science SCI-02 Geant4 simulations
PLD-10 The EPD-E shall have a ΔE/E ≤ 50% Primary science SCI-01 Test pulser and electron gun testing
Systems Requirements Review- 61 2/8/2015
DETECTOR STACK DESIGN EPD-I
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-08 The EPD-I shall be capable of deflecting electrons less than 500 keV
Want to reject electrons from EPD-I
EMWorks simulations and electron gun testing
PLD-15 The EPD-I shall be able to measure protons with an energy range of 50 to 300 keV Secondary science SCI-03 Geant4 simulations
PLD-16 The EPD-I shall have a ΔE/E ≤ 50% Secondary science SCI-03 Test pulser, ion sources, magnetic spectrometer
Systems Requirements Review- 62 2/8/2015
MECHANICAL DESIGN
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-12 The EPD-E shall be capable of measuring electron counts from 10,000 to 50,000 counts/second.
Primary science
SCI-02
Test pulser and electron gun testing
PLD-14
The EPD-E shall be capable of measuring a flux in the range of 102 to 107 counts/(cm2·s·sr). Maximum expected electron fluxes: E1 (0.05 to 0.5MeV): ~107 counts/(cm2·s·sr) E2 (0.5 to 1.0MeV): ~ 105 counts/(cm2·s·sr) E3 (1.0 to 1.5MeV): ~5.0 x 105 counts/(cm2·s·sr)
PLD-18 The EPD-I shall be capable of measuring ion counts from 10,000 to 50,000 counts/second.
Secondary science
SCI-03
Test pulser and possibly ion sources PLD-20
The EPD-I shall be capable of measuring the flux of ions in the range 102 to 107 counts/(cm2·s·sr). Maximum expected proton fluxes: P1 (0.03 MeV): 1 x 107 counts/(cm2·s·sr)
Systems Requirements Review- 63 2/8/2015
MECHANICAL DESIGN
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-06
The EPDs shall be capable of rejecting side penetrating particles through a combination of shielding and coincidence logic.
We only want to see particles within the field of view of the sensor heads
Electron gun testing (pointing at the side)
Systems Requirements Review- 64 2/8/2015
SOFTWARE DESIGN
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-01 The EPDs shall be able to turn off when the sun transits their field of view.
Prevents saturation of detectors
Light source testing
PLD-11 The EPD-E shall be capable of measuring 16 sectors/spin Primary science SCI-01 Collimated light source with
rotating EPD-E
PLD-17 The EPD-I shall be capable of measuring 16 sectors/spin Secondary science SCI-04 Collimated light source with
rotating EPD-I
Systems Requirements Review- 65 2/8/2015
Mass allocated for EPD: 1075.4 g Current best estimate (CBE): 814.5 g Margin: 17.5% (142.5 g) CBE + Margin: 957.0 g Contingency: 118.4 g
MASS REQUIREMENT
EPD
Component Maturity Qty Unit Mass CBE Margin CBE+Margin EPD-E P 1 384.00 384.0 15% 442.0 EPD-I P 1 266.00 296.0 15% 340.4 EPD Analog Signal Processing Board L 1 13.00 13.0 20% 15.6 EPD Digital Board L 1 30.00 30.0 20% 36.0 FSS P 1 1.27 1.3 15% 1.5 FSS PCB, +X L 1 13.84 13.8 20% 16.6 Preamplifier and Buffer Boards P 1 36.00 36.0 15% 41.4 Payload ETC Board (LETC 1) L 1 40.44 40.4 20% 48.5
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-34 The Payload subsystem shall not exceed the mass allocated by Systems.
CubeSat design specification SYS-14
System mass documented and tracked through assembly, integration and test.
Systems Requirements Review- 66 2/8/2015
Power allocated for EPD
(during science data collection): 2.5 W Current best estimate (CBE): 1.772 W Margin: 25% (~0.43 W) CBE + Margin: 2.2 W Contingency: 0.3 W
POWER REQUIREMENT
REQ ID Requirement Rationale Parent(s) Verification Method
PLD-35
The Payload subsystem shall not exceed the power allocated in the ELFIN system power budget.
Power is limited SYS-22
Measure power consumption during component tests. Analysis of the complete set of EPD states.
Systems Requirements Review- 67 2/8/2015
IDPU REQUIREMENTS
IDPU Requirements
Pat
Systems Requirements Review- 68 2/8/2015
LIFETIME AND RADIATION
Requirement Design
IDPU-1 : IDPU shall be designed for at least a 3 month lifetime Lifetime considered in part selection, performance, and degradation.
IDPU-2: IDPU shall be designed to operate at a dose of 5 krad/yr or greater
Rad tolerant and flight heritage parts selected where feasible. Timing analyses derated for increases in propagation delay.
IDPU-3: IDPU shall be SEU tolerant.
Selective use of TMR in vulnerable FPGA registers. SECDED encoding for RAM. SECDED encoding for SD-Cards with regular repair sweeps.
Estimated SEU Rates per day per device
FPGA SRAM FPGA
Registers FPGA TMR Registers SD Card FRAM
0.05-0.14 0.0018 1.22e-5 Analysis
In Progress Analysis
In Progress
Systems Requirements Review- 69 2/8/2015
MASS
Requirement Design
IDPU-4: The IDPU shall not exceed the allocated mass. Allocated is 35.7g. CBE is 30 g, leaving 19% contingency.
Component Maturity Qty Unit mass CBE Margin CBE+Margin Comments Last updated
IDPU P 1 30.00 30.0 15% 34.5
4/23/2012 ELFIN mass budget had 80g, EPD sheet had 30g; 9/10/2014
From MassBudget-04-B.xlsx:
Systems Requirements Review- 70 2/8/2015
POWER Requirement Design
IDPU-5: IDPU shall not exceed the allocated power. Allocated in 0.9W CBE is 0.632 W leaving 42% power contingency.
IDPU-27: IDPU shall accept power at 1.5V(+-5%), 2.5V(+-5%), 3.3V(+-9%), 5V(+-10%)
All parts selected to meet or exceed power regulation margins
Four power levels 1.5V: FPGA core power 2.5V: LVDS interfaces 3.3V: LVTTL interfaces, Memories, ADCs, Oscillator 5.0V: Level shifters for multi-point UART transceiver
Provided over mezzanine connectors Power regulation and monitoring provided by SIPS
subsystem
Systems Requirements Review- 71 2/8/2015
MECHANICAL Requirement Design
IDPU-6: The IDPU shall meet the mechanical requirements specified in the mechanical ICD 001-ELFIN-MECH-ICD
IDPU is second card from the top in the instrument stack. Interfaces to above and below boards using mezzaine connectors.(2 top, 2 bottom) Card edge connector for FSS. Design approved by Payload Mechanical engineer David Leneman.
Top(inches) Bottom(render)
Systems Requirements Review- 72 2/8/2015
THERMAL
Requirement Design
IDPU-7: The IDPU shall operate within the temperatures specified in the thermal ICD(001-THRMICD). -30 to 40 C ambient temperature.
Selecting Industrial Grade Parts. Ambient -40 to 85, Junction -40 to 100
Thermal team still getting up to speed Modeling with Thermal Desktop
IDPU should be low risk. Mostly digital interfaces, primary risk is survivability Four analog interfaces for FSS. Temperature may need consideration in FSS control
law High Heat Dissipation Items
Item Power(mW) Conduction Mechanism
FPGA 298 208-pin package. Conducts through pins into PCB
Oscillator 155 High thermal coefficient staking material. (Under selection)
Conducts into PCB
SD-Cards 175 High thermal coefficient staking material. (Under selection)
Conducts into PCB
Systems Requirements Review- 73 2/8/2015
DATA INTERFACE
Requirement Design
IDPU-8: The IDPU shall receive commands from avionics subsystem through a bidirectional interface at a rate of no less than 38.4 kbps
2-wire bidirectional UART interface at 76.8 kbps, shared with telemetry interface.
IDPU-9: The IDPU shall send commands to the avionics subsystem through a bidirectional interface at a rate of no less than 38.4 kbps
2-wire bidirectional UART interface at 76.8 kbps, shared with telemetry interface.
UART interface. 8-bit payload. No parity. One stop bit. Avionics: 427 clocks per bit @ 32.768 MHz oscillator. Gives bit rate of 76.74
kbps. For baud rate matching error of < 0.1% SIPS/FGM 16 clocks per bit @ 16.384 MHz clock. 1024 kbps. 0 matching error EPD 64 clocks per bit @ 65.536 MHz clock. 1024 kpbs. 0 matching error Data are transmitted least significant bit first and most significant byte first
Idle (high)
Start (low)
D0 (LSB) D1 D2 D3 D4 D5 D6 D7
(MSB) Stop (high)
Idle (high)
Systems Requirements Review- 74 2/8/2015
COMMANDING
Requirement Design
IDPU-15: The IDPU shall be capable of powering the EPD and/or the FGM off and operating normally in each possible power state
Five instrument modes support all possible power states
IDPU-16: The IDPU shall be able to read or write any non-volatile memory by command
SD-cards, configuration registers, and FRAM are in a shared address space
IDPU-17:The IDPU shall validate commands before execution
Avionics command format includes an 8-bit CRC for each packet
IDPU-18: The IDPU shall have the capability to disable all autonomous functions by command
Closed loop controller enable/disable bits stored in configuration registers
IDPU-19: The IDPU shall provide the capability to modify all IDPU flight software
Writing to FRAM addresses and commanding a reset, reloads a new copy of flight software
IDPU-20: The IDPU shall provide all initialization parameters to instruments as specified by instrument
Each instrument has a load sequence which is stored in nonvolatile memory. 28 bytes are sent to FGM on startup. 384 bytes sent to EPD on startup
Systems Requirements Review- 75 2/8/2015
SYNCHRONIZATION & TIMING
Requirement Design
IDPU-24: The IDPU shall initialize an instrument data time tagging clock with 6-byte RTCC data provided by the C&DH subsystem
Avionics provides RTCC command at 1-second rollover on spacecraft clock
IDPU-25: The IDPU shall initialize a subsecond counter with a resolution of at least 5 ms at the time that it receives RTCC data from the C&DH subsystem
IDPU initializes 2-byte subsecond counter at reception of RTCC. Increments every 500 clocks. Resolution is 1 second /65536 = ~15.3 microseconds
IDPU-26: The IDPU shall time tag all data products using the 8-byte time tag and subsecond counter
Time tags will be inserted into memory when data is collected in between data samples
RTCC Format
Field SubH
Sub L 10 s 1 s 10
min 1 min 10 hr 1 hr 10
date 1 date
10 mon
1 mon 10 y 1 y
Bit Width 8 8 4 4 4 4 4 4 4 4 4 4 4 4
Byte Num 0 1 2 2 3 3 4 4 5 5 6 6 7 7
Systems Requirements Review- 76 2/8/2015
DATA RATES
Requirement Design
IDPU-10: The IDPU shall provide FGM telemetry to the C&DH subsystem at 4 or greater samples/sec
FGM generates samples at 200 sps. IDPU uses decimating LPF to reduce rate to 10 sps. Output Rate = 9 B x 10 samples = 90 bytes /sec
IDPU-11: The IDPU shall provide EPD telemetry to the C&DH subsystem at a sample rate of no less than 16 samples/spin
EPD generates samples at ~32/3 sps. IDPU uses logarithmic compression to reduce 2 byte samples to 1 byte. Output rate = 32/3 samples x (16 B+16 B +16B + 4 B) =~555 bytes/sec
IDPU-12: The IDPU shall provide SIPS housekeeping telemetry to the C&DH subsystem at a sample rate of no less than 0.01 Hz
Payload Subsystem generates housekeeping at a rate of ~64 bytes / 100 seconds = 0.64 bytes/sec (Total # of telemetry points TBD)
IDPU-14: The IDPU shall be capable of storing no less than one week of data at a data rate of ~ 4 MB/day
~2.22 MB/day @ 60 minutes of science raw ~3.33 MB/day with compressed products Each SD card is 2048 MB . 1024 MB with SECDED encoding. 308 days of storage for each SD card.
Systems Requirements Review- 77 2/8/2015
DATA PROCESSING
Requirement Design
IDPU-13: The IDPU shall be able to perform lossless compression of instrument data
MSP430 can perform compression. Still trading algorithms. LZW, Huffman, RLE, and delta encoding in trade.
IDPU-21: The IDPU shall generate secondary slow survey data products as specified.
Quick look products generated during compression mode.
EPD FGM
Fast Survey
32 sectors x 16 energies x 3 distributions + 8 noise channels x 3 distributions Per spin.
10 samples/sec
Slow Survey
2 sectors x 4 energies x 3 distributions + 8 noise channels x 3 distributions Per Spin
2/3 samples/sec
Systems Requirements Review- 78 2/8/2015
MAGNETIC SECTORING
Requirement Design
IDPU-22: IDPU shall generate a magnetic sectoring signal from the FGM data and provide it by UART command to the EPD at the start of each EPD sector
200 Hz signal used to identify peak field on configurable axis. Sector Start Cmd resets EPD histograms to zero and swaps EPD double buffer.
Systems Requirements Review- 79 2/8/2015
FINE SUN SENSOR
Requirement Design
IDPU-28: IDPU send the preamp disable command to the EPD when the FSS first detects sun and send the preamp enable command when the FSS first stops detecting sun
Attitude algorithm simplified into simple threshold for FPGA. Reads at 100 Hz.
|(C+D)-(A+B)| < tX |(A+D)-(B+D)| < tY (A+B+C+D) > tD
Systems Requirements Review- 80 2/8/2015
Electron Losses and Fields Investigation
System Requirements Review
Switching Instrument Power Supply (SIPS)
Ryan Caron
Los Angeles, California
February 8th, 2015
Systems Requirements Review- 81 2/8/2015
EXPLODED VIEW
Systems Requirements Review- 82 2/8/2015
SIMPLIFIED POWER TOPOLOGY
Systems Requirements Review- 83 2/8/2015
REQUIREMENTS REQ ID Requirement Parent(s) Verification Method Rationale
PLD-30 The Switching Instrument Power Supply (SIPS) shall be capable of providing power to the energetic particle detectors
T: Dummy loads, functional tests, and EMIC tests
No voltage regulators are built into EPD.
PLD-31 The SIPS shall be capable of providing power to the flux-gate magnetometer electronics
T: Dummy loads, functional tests, and EMIC tests
Higher power efficiency is needed than what the FGM’s voltage regulators offer
PLD-32 SIPS shall be capable of receiving power from the Power subsystem
T: Functional tests with adjustable bench supply, followed by functional tests with SBPCB and associated components
Direct connection to the AeroCube EPS is needed to because volume for an intermediate converter is not available
PLD-33 SIPS shall be capable of providing power and housekeeping telemetry to the IDPU
T: Functional test with IDPU, dummy loads
Telemetry is needed to assess health and efficiency. SIPS has no non-volatile memory.
PLD-37
SIPS power line characteristics (i.e. transients, in-rush, ripple, stability, etc) shall be as agreed upon and documented in the Instrument-SIPS ICDs
T: Dummy loads
These power supply specifications have a direct correlation to instrument performance and reliability
PLD-38
SIPS shall provide Instrument regulated, switched and current-limited voltages as detailed in the Instrument-SIPS ICDs
T: Engineering Model SIPS board testing
Certain protection methods are required to mitigate latch-ups and other malfunctions
PLD-39 SIPS shall not be damaged by undervoltage conditions T: Undervoltage Lockout Self explanatory
Systems Requirements Review- 84 2/8/2015
MASS REQ ID Requirement Parent(s) Verification Rationale
PLD-34
The Payload subsystem shall not exceed the mass allocated by Systems
SYS-14
T/A: System mass documented and tracked through assembly, integration and test
Typical resource constraints
Mass allocated for SIPS: 35.7 g Current best estimate (CBE): 30 g Margin: 15 % (4.5 g) CBE + Margin: 34.5 g Contingency: 1.2 g
Payload Component Maturity Qty Unit mass CBE Margin CBE+Margin
SIPS P 1 30.00 30.0 15% 34.5
Systems Requirements Review- 85 2/8/2015
POWER REQUIREMENTS
REQ ID Requirement Parent(s) Verification Method Rationale
PLD-35
The Payload subsystem shall not exceed the power allocated in the ELFIN system power budget
SYS-22
T/A: Measured power consumption data during component tests; Analysis of the complete set of Instrument states.
Typical resource constraints
Mode: Science Data Collection [mW] Allocation CBE Margin IDPU 675 540 25% EPD 2,869 2,300 25% FGM 804 643 25% Total 4,348 3,483 25%
Mode: Communications / Transmit
Mode: Science Data Processing [mW] Allocation CBE Margin IDPU 675 540 25% EPD 0 0 0 FGM 0 0 0 Total 675 540 25%
[mW] Allocation CBE Margin IDPU 675 540 25% EPD 0 0 0 FGM 0 0 0 Total 675 540 25%
Systems Requirements Review- 86 2/8/2015
EMI/C with instruments Both EPD and FGM are sensitive Magnetic compatibility has implications on inductor
selection Galvanic isolation not required Fault Detection & Correction
EPD ADCs known to latch-up & overcurrent Efficient supply
Limited power on a CubeSat Allows wider ambient temperature range
Switches Instruments are normally run in tandem, but there are
regions where only one instrument is used Separate mode just powers IDPU for data compression
REQUIREMENTS & SPECIFICATIONS
Systems Requirements Review- 87 2/8/2015
~ 3.4 x 3.7” PCB 11 in2 after cutouts
Four #2-56 fasteners Power mezzanine
Serves as “backplane” 60 pins, Tyco Electronics
Free-Height 0.8mm Stack-height adjustable
from 5-9mm in 1mm steps Data mezzanine
40 pins, TE FH 0.8mm Power input
4 pin Datamate J-Tek connector (2mm pitch)
MECHANICAL OUTLINE
Systems Requirements Review- 88 2/8/2015
ADCS REQUIREMENTS
ADCS Requirements
Oliver
Systems Requirements Review- 89 2/8/2015
ADCS REQUIREMENTS REQ ID Requirement Rationale Parent(s) Verification Method
ADCS-01 The ADC subsystem shall be capable of producing and maintaining a spin rate between 10 and 30 rpm to within ±2 rpm.
Mission requires certain spin rate to collect sufficient amount of data for science.
MSN-10, MSN-09
A: Software simulation of initial conditions and defined orbit
ADCS-02 The ADC subsystem shall be capable of ±5 degrees of attitude control
Science mission need specific orientaiton to collect data.
MSN-08
A: Software simulation of initial conditions and defined orbit
ADCS-03 The ADC subsystem shall be capable of ±3 degrees of attitude knowledge
Science mission need to match its collected data with orientation informaiton.
MSN-08
A: Software simulation of initial conditions and defined orbit
ADCS-04 The ADC system shall be capable of automatically detumbling ELFIN after deployment from the P-POD.
ADCS need automatic detumble capabilities in case it it couldn't communicate with the ground.
MSN-09 A/T: Software Simulation and spin testing
Systems Requirements Review- 90 2/8/2015
ADCS REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
ADCS-05
The integration time of all ADCS sensors shall be sufficiently low so that they are capable of operating while the spacecraft is spinning at rate of up to 30 rpm
Low integration time ensure manuevering efficiency at high spin rate.
MSN-09 T: Spin sensors testing
ADCS-06 The ADC subsystem shall have at least two separate sensors capable of being processed onboard for maneuvers.
Two sensors provide fail safe capability.
I/T: Inspection of Development Model and hardware testing
ADCS-07
The ADC subsystem shall be capable of running a deperm cycle after maneuvers to ensure the magnetic moment of the spacecraft is less than 1 nT as measured at the magnetometer
Deperm cycle is needed to clean the build up of magnetic field by torquing.
T: Testing in UCLA in house magnetic testing facility.
ADCS-10 The ADC subsystem shall not exceed the mass allocated by Systems SYS-14 T: Instruments will
be weighed
ADCS-11 The ADC subsystem shall not exceed the power allocated in the ELFIN system power budget SYS-22
T/A: Measured power consumption data during component tests
Systems Requirements Review- 91 2/8/2015
C&DH REQUIREMENTS
REQ ID Requirement Rationale Metric
C&DH-01 C&DH shall be capable of processing housekeeping data
Housekeeping data is used to verify the status of the different parts of the spacecraft
T: Software testing on development, engineering, and flight hardware.
C&DH-02 C&DH shall be capable of formatting and compressing housekeeping data
Format and compress to make the data more useable and take up less memory
T: Software testing on development, engineering, and flight hardware.
C&DH-03 C&DH shall be capable of processing commands from the ground station
Ensure that spacecraft can accept and interpret commands from the ground
T: Software testing on development, engineering, and flight hardware.
C&DH-04 C&DH shall be capable of disabling the spacecraft communication system on command from the ground station
Requirement from FCC
T: Software testing on development, engineering, and flight hardware.
C&DH-05 C&DH shall be capable of single error correction and double error detection on all memory except program memory.
Error mechanism to mitigate and identify errors in memory corresponding to stored data
T: Software testing on development, engineering, and flight hardware.
Systems Requirements Review- 92 2/8/2015
C&DH REQUIREMENTS
C&DH-06 C&DH shall be capable of interfacing with the communications system to transmit housekeeping and science data using volatile memory.
Ensure that data can be sent to the ground
T: Software testing on development, engineering, and flight hardware.
C&DH-07 C&DH shall be capable of putting the spacecraft in safe mode
When an error occurs, the spacecraft is placed into safe mode to prevent further actions from being taken while the error still exists
T: Software testing on development, engineering, and flight hardware.
C&DH-08 C&DH shall be capable of resetting itself in the event of an error
Reset the spacecraft if an error occurs, which can possibly fix the error
T: Software testing on development, engineering, and flight hardware.
C&DH-09 C&DH shall be capable of executing scheduled events sent by the ground station
Scheduled events allow the spacecraft to perform tasks when not in direct contact with the ground
T: Software testing on development, engineering, and flight hardware.
C&DH-10 C&DH shall be capable of jumping the clock on command from the ground station
Allows the clock on the spacecraft to be calibrated to the one on the ground
T: Software testing on development, engineering, and flight hardware.
C&DH-11
Engineering magnetometer telemetry shall be collected at a sufficient rate to implement the ADCS control law algorithm as specified by the ADCS subsystem.
Need ADCS to control spacecraft attitude
T: Software testing on development, engineering, and flight hardware.
Systems Requirements Review- 93 2/8/2015
C&DH REQUIREMENTS
C&DH-12 All software shall support a sleep-wake cycle Saves power
T: Software testing on development, engineering, and flight hardware.
C&DH-13 All software shall respond to a command with a latency of less than 100 ms.
Permits sufficiently rapid communication with the ground and subsystems
T: Software testing on development, engineering, and flight hardware.
C&DH-14 All software must be tolerant to single event upsets. (SEUs)
Ensure that the software is radiation tolerant
T: Software testing on development, engineering, and flight hardware.
C&DH-17 Throughput speed to the Communications subsystem shall meet or exceed 76.8k baud.
Defines the interface to subsystems, sufficiently rapid to have relatively low bus utilization and not bottleneck at the radio
T: Software testing on development, engineering, and flight hardware.
C&DH-18
Real time calendar clock(RTCC) data shall be provided to IDPU as the first command after the IDPU is powered up. This command shall arrive with TBD latency and +-TBD absolute variation(jitter) from the 1 second rollover on the avionics RTCC
Ensure the IDPU has the correct time for its data collection within a certain margin
T: Software testing on development, engineering, and flight hardware.
Systems Requirements Review- 94 2/8/2015
Electron Losses and Fields Investigation
COMM Subsystem
Requirements
Kyle Colton
Los Angeles, California
Systems Requirements Review- 95 2/8/2015
COMM REQUIREMENTS REQ ID Requirement Rationale COMM-01 There shall be at a minimum of 6dB margin
in the telecommunications link analysis both for the uplink and the downlink at 10 deg
elevation mask.
Allow for clear communications even with
unforeseen losses.
COMM-02 The communication system shall be capable of transmitting and receiving data while
spinning at up to 30 rpm.
Maintain the Link through nominal mission spin with
margin
COMM-03 The communication system shall transmit at the minimum energy per bit required to close
the link with margin.
Lowest possible power load while closing the link to
reduce load on spacecraft
Systems Requirements Review- 96 2/8/2015
COMM REQUIREMENTS REQ ID Requirement Rationale COMM-04 At least two command stations shall be
maintained. Retain cessation of
transmission in emergency conditions
COMM-05 Command stations shall provide reasonable redundancy in the event of infrastructure failure (power loss) or natural disaster
(earthquake).
Retain cessation of transmission in emergency
conditions
COMM-06 Downlinks to auxiliary (community) earth stations shall be facilitated without requiring said stations to command the satellite. This is expected by scheduling blind downlinks
aboard the satellite based upon prior demonstrations by the community station of its reliability and availability, likely from live
telemetry beacon reception.
Simplifying auxiliary station downlink requirements
Systems Requirements Review- 97 2/8/2015
COMM REQUIREMENTS REQ ID Requirement Rationale COMM-07 Command uplink to the satellite shall be
encrypted and immune to playback attack. Prevent unauthorized
command of the spacecraft
COMM-08 The satellite shall have two independent RF inhibits, enabling RF power output greater
than 1.5W
Conform with LSP regulations to allow greater
transmit capabilities
COMM-09 The UCLA earth stations and their operators shall be capable of establishing command uplink to the satellite within 3 weeks of deployment from the launch vehicle.
Efficiently use the limited on-orbit time of the
spacecraft
Systems Requirements Review- 98 2/8/2015
COMM REQUIREMENTS REQ ID Requirement Rationale COMM-10 The UCLA earth stations, prior to launch of
the satellite, shall be tested with attenuators and long range testing to verify uplink and
downlink capability with an ELFIN engineering unit, likely with a balloon
mission.
Ensure earth segment communications meet or exceed requirements for communication by testing
COMM-11 The UCLA earth stations, prior to launch of the satellite, will be tested with orbital assets
by fostering relations with other mission teams, beginning with beacon and data
collection and culminating in a test uplink.
Ensure earth segment communications meet or exceed requirements for communication by testing
COMM-12 The Communications subsystem shall not exceed the mass allocated by Systems
Limited spacecraft mass is available for
communications
Systems Requirements Review- 99 2/8/2015
COMM REQUIREMENTS REQ ID Requirement Rationale COMM-13 The Communications subsystem shall not
exceed the power allocated in the ELFIN system power budget
Limited spacecraft power is available for
communications
Systems Requirements Review- 100 2/8/2015
Electron Losses and Fields Investigation
Systems Review
Electrical Power Subsystem
Akshaya Subramanian
Los Angeles, California February 8, 2015
Systems Requirements Review- 101 2/8/2015
EPS REQUIREMENTS REQ ID Requirement Parent(s) Verification Method Verification
Document Rationale Status
PWR-01 Total stored chemical energy in ELFIN shall not exceed 100 Watt-Hours SYS-25 Design and testing Thermal
PWR-02
No electronics shall be active during launch to prevent any electrical or RF interference with the launch vehicle and primary payloads. CubeSats with batteries shall be fully deactivated during launch or launch with discharged batteries.
SYS-25 Deployment switch testing during random vibe tests.
Launch Provider Requirements
L
PWR-03
ELFIN shall include at least one deployment switch on the designated rail standoff (shown in Figure 5 in CubeSat Design Spec) to completely turn off satellite power (including power to real time clocks) once actuated. In the actuated state, the deployment switch shall be centered at or below the level of the standoff.
SYS-25 Hardware in the loop testing of deployment switches.
Launch Provider Requirements
PWR-04
All electrical GSE connectors on ELFIN shall be within the designated Access Port locations (green shaded areas shown in Figure 5 in CubeSat Design Spec).
SYS-25 CAD and integration. Systems
PWR-05
EPS shall be capable of interfacing with ground support equipment to provide diagnostics and battery charging while the deployment switches are depressed
SYS-25 Hardware in the loop testing of deployment switches.
Power
Systems Requirements Review- 102 2/8/2015
EPS REQUIREMENTS REQ ID Requirement Parent(s) Verification Method Verification
Document Rationale Status
PWR-06
ELFIN shall include a Remove Before Flight (RBF) pin or launch with batteries fully discharged. The RBF pin shall be removed from the CubeSat after integration into the P-POD. The pin shall be accessible from the Access Port locations and shall cut all power to the satellite once it has been inserted.
SYS-25
Hardware in the loop testing and compliance with P-POD Final Integration Procedures.
Launch Provider Requirement
PWR-07
ELFIN shall be capable of generating power sufficient power to prevent brownout while spinning.
MSN-09 Hardware in the loop testing. Power/ Thermal
PWR-08
The power system shall be capable of supplying power for at least three months (minimum)
MSN-07 Simulation. Mission Life
PWR-09
The Electrical Power Subsystem shall be capable of supplying power through eclipse in all scenarios, including science data collection mode, through the primary mission
SYS-27 Hardware in the loop testing. Mission Life
PWR-10
The Electrical Power Subsystem shall be capable of supplying sufficient power for all spacecraft modes under nominal operating conditions
PWR-09 Hardware in the loop testing. Mission Life
Systems Requirements Review- 103 2/8/2015
EPS REQUIREMENTS REQ ID Requirement Parent(s) Verification Method Verification
Document Rationale Status
PWR-11
The Electrical Power Subsystem shall recover from any brownouts and still be able to provide power to the spacecraft afterwards.
SYS-28 Hardware in the loop testing of EPS with dead batteries.
Thermal
PWR-12 Deleted, moved to systems level (SYS-26)
PWR-13 Inhibits are required to be independent. Common cause failures are to be considered.
SYS-26 Hardware in the loop testing. Launch Provider
Requirement
PWR-14 The electrical inhibit design shall allow for positive verification of inhibit state SYS-26 Hardware in the loop
testing. Launch Provider Requirement
PWR-15 ELFIN shall have two inhibits between the solar array and the load and the battery and load.
SYS-26 Hardware in the loop testing. Launch Provider
Requirement
Systems Requirements Review- 104 2/8/2015
EPS REQUIREMENTS REQ ID Requirement Parent(s) Verification Method Verification
Document Rationale Status
PWR-16 EPS power line characteristics shall be as agreed upon and documented in the EPS-bus and EPS-instrument ICDs
SYS-23 A/T Systems
PWR-17 The Power subsystem shall not exceed the mass allocated by Systems SYS-14 T: Components will be
weighed MassBudget-##-B.xlsx Systems
PWR-18 The Power subsystem shall not exceed the power allocated in the ELFIN system power budget
SYS-22 PowerBudget-##-B.xlsx Systems
PWR-19 Any excess solar power shall be used to charge the batteries SYS-22 Mission Life
PWR-20 All EPS components shall be kept within their operational thermal limits during all modes of operation
SYS-27 Mission Life
Systems Requirements Review- 105 2/8/2015
STRUCTURES & MECH REQUIREMENTS
Structures and Mechanisms
Chris Yu
Systems Requirements Review- 106 2/8/2015
MECH REQUIREMENTS (1/2) REQ ID Requirement Parent(s) Verification Method
STRC-01 Aluminum alloys used in structural applications shall be resistant to general corrosion, pitting, intergranular corrosion, and stress corrosion cracking. NASA-STD-6061 I: Inspection of Development
Model
STRC-02 Deployables shall be constrained by ELFIN MSN-11 I: Inspection of Development Model and random vibe testing.
STRC-03 Rails shall have a minimum width of 8.5mm. MSN-11 I: Inspection of Development Model and QA
STRC-04 The rails shall not have a surface roughness greater than 1.6 μm. MSN-11 I: Stock preparation
STRC-05 The edges of the rails shall be rounded to a radius of at least 1 mm MSN-11 I: Inspection of Development, Engineering, and Flight Model, and QA
STRC-06 The ends of the rails on the +-Z face shall have a minimum surface area of 6.5 mm x 6.5 mm contact area MSN-11
I: Inspection of Development, Engineering, and Flight Model, and QA
STRC-07 At least 75% of the rail shall be in contact with the P-POD rails. 25% of the rails may be recessed and no part of the rails shall exceed the specification. MSN-11 I: Inspection of Development,
Engineering, and Flight Model
STRC-08 Aluminum 7075, 6061, 5005, and/or 5052 shall be used for both the main structure and the rails. MSN-11 I: Inspection of Development,
Engineering, and Flight Model
STRC-09 The CubeSat rails and standoff, which contact the P-POD rails and adjacent CubeSat standoffs, shall be hard anodized aluminum to prevent any cold welding within the P-POD.
MSN-11 I: Inspection of Development, Engineering, and Flight Model
Systems Requirements Review- 107 2/8/2015
MECH REQUIREMENTS (2/2)
REQ ID Requirement Parent(s) Verification Method
STRC-10 All antennas shall be capable of deploying while ELFIN is tumbling. T/A: Thorough testing of all deployable antennas to ensure a minimum 99.9% success rate.
STRC-11 The ratio of the major moment of inertia to the intermediate moment of inertia shall be greater than 1.2 MSN-11 I/T: Evaluation of Development
Model and spin testing.
STRC-12 The structure shall not use magnetic materials. SYS-21 T: Testing in UCLA in house magnetic testing facility.
STRC-13 The spacecraft shall be capable of deploying the stacer T: Deployment tests
STRC-14 Structures shall be capable of constraining the deployables while the spacecraft is stowed, transported, launched I: Inspection of Development,
Engineering, and Flight Model
STRC-15 The center of gravity shall be located within 2 cm from its geometric center in the X and Y directions
MSN-11 I: Inspection of Development, Engineering, and Flight Model
STRC-16 The center of gravity shall be located within 7 cm from its geometric center in the Z direction. MSN-11
I: Inspection of Development, Engineering, and Flight Model
STRC-17 The length, rotations and bending of the stacer shall be known to at least TBD cm D: Flight Demonstration
STRC-18 The Structures subsystem shall not exceed the mass allocated by Systems SYS-14 I: Components will be weighed
STRC-19 The Structures subsystem shall not exceed the power allocated in the ELFIN system power budget SYS-22
T/A: Measured power consumption data during component tests
STRC-20 The P-POD rails and walls shall not to be used to constrain deployables. MSN-11 I: Inspection of Development, Engineering, and Flight Model
STRC-21 ELFIN's dimensions shall comply with the CubeSat specification (100.0±0.1 x 100.0±0.1 x 340.5±0.3 mm). MSN-11
I: Inspection of Development, Engineering, and Flight Model
STRC-22 ELFIN shall have the coordinate system with the -Z face of the CubeSat inserted first into the P-POD and the +Y face as the top face of the CubeSat SYS-25
Systems Requirements Review- 108 2/8/2015
THERMAL REQUIREMENTS
Thermal Requirements
Chris Knapp
Systems Requirements Review- 109 2/8/2015
THERMAL REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
THRM-01
Temperature sensors shall be installed within the CubeSat and be accessible during thermal testing whether the CubeSat is powered on or not.
Allows for diagnostics of potential thermal issues during testing and operations
UNP-NS8-Userguide (p.62) I: Inspection
THRM-02 The spacecraft TCS shall keep all bus components within operating temperatures
Components need to be at a certain temperature to operate within specification.
SYS-30 A/T: Thermal analysis; Verified during Thermal Vacuum Testing
THRM-03 The spacecraft TCS shall keep all bus components within survival temperatures
Components need to be at a certain temperature to prevent any damage to that component.
SYS-29 A/T: Thermal analysis; Verified during Thermal Vacuum Testing
Systems Requirements Review- 110 2/8/2015
THERMAL REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
THRM-04 The spacecraft TCS shall not exceed the mass allocated by Systems
Limited spacecraft mass available for thermal control
SYS-14 I: Components will be weighed
THRM-05 The spacecraft TCS shall not exceed the power allocated in the ELFIN system power budget
Limited spacecraft power available for thermal control
SYS-22 A/T: Measured power consumption data during component tests
THRM-06
No component shall be powered on when its temperature is below the minimum turn-on temperature as specified in the subsystem ICDs
Components have a minimum temperature when it can be turned on.
SYS-31 A/T: Thermal analysis; Verified during Thermal Vacuum Testing
Systems Requirements Review- 111 2/8/2015
Electron Losses and Fields Investigation
ESN Subsystem Requirements
Kyle Colton
Los Angeles, California
Systems Requirements Review- 112 2/8/2015
ESN REQUIREMENTS REQ ID Requirement Rationale
ENS-01 The ELFIN earth station shall be RF and data compatible with the space segment on both
the telemetry and the command link.
The ELFIN earth station shall be RF and data
compatible with the space segment on both the
telemetry and the command link.
ESN-02 The ELFIN earth station shall be RF and data compatible with the space segment on both
the telemetry and the command link.
Enables basic communications operations
ESN-03 The ELFIN earth stations shall be able to close the telemetry link at data rates up to 19.2
kbaud with a link margin of at least 6 dB at all elevations >10 degrees.
Allow for clear communications even with
unforeseen losses.
Systems Requirements Review- 113 2/8/2015
ESN REQUIREMENTS REQ ID Requirement Rationale
ENS-04 The ELFIN earth stations shall be capable of recovering a telemetry data volume of TBD
ESN must be able to support the volume to be
downlinked by the spacecraft
ESN-05 The ELFIN earth stations shall parse received telemetry by data type, record all data locally,
and route data as soon as possible to command and control workstations.
Keep a local backup for contingencies, and relay
the data so it can be acted on quickly
ESN-06 The ELFIN earth stations shall buffer recovered telemetry data for at least 7 days
Allow for clear communications even with
unforeseen losses.
Systems Requirements Review- 114 2/8/2015
ESN REQUIREMENTS REQ ID Requirement Rationale
ENS-07 The ELFIN earth stations shall provide command capabilities to allow closure of the
command link to an altitude fo 1250km with a link margin of at least 6dB at all elevations
>10 degrees.
ESN must be able to support all possible orbits of the ELFIN spacecraft
while maintaining appropriate margins
ESN-08 The ELFIN earth station shall be capable of tracking TLEs to within 5 degrees.
Minimize error in tracking
ESN-09 The ELFIN earth station shall support a TBD protocol for command verification.
Make sure that commands are confirmed and correct
ESN-10 The ELFIN earth stations shall maintain at least two geographically diverse stations.
Retain cessation of transmission in emergency
conditions
Systems Requirements Review- 115 2/8/2015
ESN REQUIREMENTS REQ ID Requirement Rationale
ENS-11 The ELFIN earth stations shall track the use of TLEs to be able to recall which TLE was used
for which pass.
Enables reconstruction of passes to troubleshoot and
diagnose errors
ESN-12 The ELFIN earth stations shall be able to operate without power and network for at
least 24 hours.
Ensure no loss of capability for minor upsets and
problems
ESN-13 In stations where an array is used, the antennas must stay within TBD degrees of the
array average.
Misalignment causes losses in the link budget
Systems Requirements Review- 116 2/8/2015
ESN REQUIREMENTS REQ ID Requirement Rationale
ENS-14 Weatherizing requirement Unprotected equipment can experience unexpected fatiguing and stress and possible early end of life
ESN-15 All ELFIN earth stations shall comply with OSHA, UCLA EHS, and other applicable regulatory bodies in maintaining a safe
working environment
UCLA / ELFIN employees and volunteers must be able to safely work on or near the earth stations
ESN-16 All ELFIN earth stations shall be repairable or replaceable within TBD days
Minimize loss of capability for major problems
Systems Requirements Review- 117 2/8/2015
OPERATIONS REQUIREMENTS
Mission Operations
Lydia Bingley
Systems Requirements Review- 118 2/8/2015
• GS.MOC-1. All aspects of ELFIN Mission Operations command and control shall be performed at the Operations Center, located at UCLA/IGPP.
[Rationale: Integrated Operations Center reduces overall ground system complexity.]
• GS.MOC-2. The Operations Center shall provide hardware, software and IT networking systems to support all mission operation functions.
[Rationale: Provides infrastructure to perform all tasks required to operate the satellite and to recover all science and engineering data via primary and secondary Earth Stations.]
• GS.MOC-3. The Operations Center shall interface with the ELFIN Earth Stations on Knudsen, Boelter, and WPI.
[Rationale: Ensures seamless data flow from spacecraft to ground system elements and vice versa, and exchange of all required data products.]
• GS.MOC-4. The Operations Center shall provide secure data interfaces to allow for remote operation and end-to-end data flow testing during mission integration.
[Rationale: Allow for end-to-end data compatibility testing, telemetry page development, simulations and operator training.]
GROUND SYSTEMS REQUIREMENTS
Systems Requirements Review- 119 2/8/2015
GS.OPS-1. Elfin Mission Operations shall support all phases of the mission.
[Rationale: Mission Operations include pre-launch, early orbit, normal and contingencies to minimize software risks.]
GS.OPS-2. A complete set of ephemeris and mission planning products shall
be generated to support all mission planning functions, ground contact scheduling and generation of command loads.
[Rationale: Generate all products based on latest state vector.]
GS.OPS-3. Mission planning functions shall ensure the probe and payloads are configured and operated according to specifications, and yield optimum science data by coordinating science requirements, engineering constraints, and resource consumption.
[Rationale: Maintain optimum operational status and ensure science goals are met.] GS.OPS-4. ELFIN state-of-health shall be monitored during real-time pass
supports. Post-pass telemetry playback shall be used to examine back-order data for limit violations and/or anomalies.
[Rationale: Monitor state-of-health throughout entire orbit]
MISSION OPERATIONS REQUIREMENTS
Systems Requirements Review- 120 2/8/2015
GS.OPS-5. The Operations Center shall include data trending to establish baseline parameters and to uncover any developing anomalous conditions early on.
[Rationale: Provide operational baseline and prevent risk to flight hardware due to out-of-limit operation.]
GS.OPS-6. All critical commands and flight software patches shall be verified prior
to upload. [Rationale: Minimize the risk to flight hardware and software.] GS.OPS-7. Mission operations shall have knowledge of the spacecraft position
within +- 40km along track, 200km across the track.
[Rationale: Necessary for accurate ground antenna point and science requirements.] GS.OPS-8. Anomaly resolution shall be conducted in consultation with pertinent
subsystem engineers, instrument scientists and project management personnel.
[Rationale: Recover bus and instruments to a safe operating state as quickly and efficiently as possible.]
MISSION OPERATIONS REQUIREMENTS
Systems Requirements Review- 121 2/8/2015
GS.OPS-9. Synchronization and maintenance of on-board memory shall be managed by the Mission Operations Center.
[Rationale: Required for determining packet APIDS and knowledge of current commands in on-board scheduler.] GS.OPS-10. The Operations Center shall keep an archive of Two Line Elements (TLEs) used throughout the mission [Rationale: TLEs are updated frequently; we need to be able to track which orbital elements were used for analysis and processing at different times in the mission] GS.OPS-11. Mission Operations is responsible for on board clock synchronization and UT determination
[Rationale: On board clocks drift at different rates]
MISSION OPERATIONS REQUIREMENTS
Systems Requirements Review- 122 2/8/2015
GS.FD-1. All attitude maneuvers shall be carefully planned and validated prior to execution.
[Rationale: To ensure that critical maneuver commands are correct and the results are as intended.]
GS.FD-2. Attitude determination shall be ground based and shall be determined from magnetometer data.
[Rationale: Required to fully resolve the attitude of the spacecraft. ]
GS.FD-3. Flight dynamics shall generate predicted and definitive spacecraft ephemeris data and orbital events based on recent TLE’s.
[Rationale: Spacecraft’s ability to determine its position in space is limited to the onboard clock. ]
FLIGHT DYNAMICS REQUIREMENTS
Systems Requirements Review- 123 2/8/2015
GS.SOC-1. Science operations shall process data from raw telemetry packets to Level 0, 1, and 2 within 24 hours of receipt on the ground.
[Rationale: In order to ensure data quality by early examination of science and housekeeping data.]
GS.SOC-2. Data products shall be distributed to the science community and archived.
[Rationale: To complete the science requirements as defined by the mission proposal and provide easy access to the data.]
GS.SOC-3. Science Operations shall generate planning requests for retransmission of corrupt or missing packets.
[Rationale: To ensure any missed or corrupt packets are recovered. ]
GS.SOC-4. Calibration files shall be maintained by science processing and updated as needed.
[Rationale: To account for changes in instrument and spacecraft performance during the course of the mission.]
SCIENCE OPERATIONS REQUIREMENTS
Systems Requirements Review- 124 2/8/2015
EGSE REQUIREMENTS
I&T: Electrical Ground Support Equipment
Requirements Michael Anderson
Systems Requirements Review- 125 2/8/2015
EGSE REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
GSE-01 Electrical Ground Support Equipment shall be capable of performing battery charging and discharging while the satellite is inhibited.
For verifying inhibits requirements
UNP-NS8-Userguide_IR (UNP 13)
I: by design
GSE-02 Electrical Ground Support Equipment shall be capable of performing inhibit actuation (set/reset inhibits) if applicable.
For verifying inhibits requirements
UNP-NS8-Userguide_IR (UNP 14)
I: by design
GSE-03 Electrical Ground Support Equipment shall be capable of powering the satellite while the satellite is inhibited.
For verifying inhibits requirements
UNP-NS8-Userguide_IR (UNP 15)
I: by design
GSE-04
Electrical Ground Support Equipment shall be capable of supporting functional testing of the satellite, including subsystem level and full “day in the life” testing.
For verifying functional requirements
UNP-NS8-Userguide_IR (UNP 16)
I: by design
Systems Requirements Review- 126 2/8/2015
EGSE REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
GSE-05 Electrical Ground Support Equipment shall be self-contained and portable.
So we can take GSE to the integrator
UNP-NS8-Userguide_IR (UNP 17)
I: by design
GSE-06 Electrical Ground Support Equipment shall be capable of command and control of the satellite without free radiation of RF energy.
For functionaility tests involving magnetic cleanliness
UNP-NS8-Userguide_IR (UNP 18)
I: by design
GSE-07 Electrical Ground Support Equipment shall be capable of command and control of the satellite through radios and RF.
For testing communications functionaility
UNP-NS8-Userguide_IR (UNP 19)
I: by design
GSE-08 Battering charging equipment in the Electrical Ground Support Equipment shall be current limited by design.
To prevent damage to the power subsystem during I&T
UNP-NS8-Userguide_IR (UNP 20)
I: by design
Systems Requirements Review- 127 2/8/2015
EGSE REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
GSE-09 Battery charging equipment in the Electrical Ground Support Equipment shall provide monitoring and protection to prevent battery damage or failure.
To prevent damage to the power subsystem during I&T
UNP-NS8-Userguide_IR (UNP 21)
I: by design
GSE-10 The main power switch shall be provided with an indicator light. To avoid damaging
the equipment
UNP-NS8-Userguide_IR (UNP 22)
I: by design
GSE-11 All Electrical Ground Support Equipment switches or buttons shall be clearly labeled. To avoid damaging
the equipment
UNP-NS8-Userguide_IR (UNP 23)
I: by design
GSE-12 Circuit protection shall be installed on primary circuits, on the load lines. To avoid damaging
the equipment
UNP-NS8-Userguide_IR (UNP 24)
I: by design
Systems Requirements Review- 128 2/8/2015
EGSE REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
GSE-13 Circuit protection devices shall be readily accessible for inspection, reset, or replacement. To avoid damaging
the equipment
UNP-NS8-Userguide_IR (UNP 25)
I: by design
GSE-14 Circuit protection shall be clearly marked with voltage present and rated amperage. To avoid damaging
the equipment
UNP-NS8-Userguide_IR (UNP 26)
I: by design
GSE-15 All wiring shall be copper. To mitigate thermal cycling stress
UNP-NS8-Userguide_IR (UNP 27)
I: by design
GSE-16 Wiring and contact materials shall be chosen such that electrical interfaces do not oxidize.
Connector reliability
UNP-NS8-Userguide_IR (UNP 28)
I: by design
GSE-17 Aluminum wire shall not be used. To mitigate thermal cycling stress
UNP-NS8-Userguide_IR (UNP 29)
I: by design
Systems Requirements Review- 129 2/8/2015
EGSE REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
GSE-18 Connectors used in the harnessing between the satellite and the Electrical Ground Support Equipment shall be scoop-proof.
To avoid damaging the equipment with improper mating
UNP-NS8-Userguide_IR (UNP 30)
I: by design
GSE-19 Electrical Ground Support Equipment shall use standard 120 V, 60 Hz, 3 prong “household” power, preferably through a single plug.
Standard equipment, grounded.
UNP-NS8-Userguide_IR (UNP 31)
I: by design
GSE-20
If batteries are included as part of the Electrical Ground Support Equipment, polarity of battery terminals shall be clearly marked and ventilation shall be provided to ensure concentrations of vapor do not reach 25% of the lower explosion limit.
Prevents explosions/fire/risk of serious injury
UNP-NS8-Userguide_IR (UNP 32)
I: by design
Systems Requirements Review- 130 2/8/2015
EGSE REQUIREMENTS
REQ ID Requirement Rationale Parent(s) Verification Method
GSE-21 Equipment shall be designed, fabricated, inspected, and tested in accordance with NFPA 70.
Follow National standards for electrical safety
UNP-NS8-Userguide_IR (UNP 33)
I: by design
GSE-22 All Electrical Ground Support Equipment shall meet the safety requirements of KHB 1700.7C and AFSPC 91-710 Vol 3 Sec 14.2.
Follow NASA/AFRL standards for electrical safety
UNP-NS8-Userguide_IR (UNP 34)
I: by design
GSE-23
All Electrical Ground Support Equipment connectors that interface with flight hardware shall be designed, built, and controlled in a manner commensurate with flight hardware with the exception of cleanliness and, therefore, shall meet applicable requirements for configuration control, quality assurance, parts & materials, etc.
Keep EGSE at similar quality of flight hardware - to protect the flight hardware
UNP-NS8-Userguide_IR (UNP 35)
I: by design