Electron Losses and Fields Investigation (ELFIN)...2015/02/08 · ELFIN shall measure the storm-...

Systems Requirements Review- 1 2/8/2015

1

Science Overview Vassilis Angelopoulos

University of California, Los Angeles


Space Weather Not Well Understood


RADIATION BELTS: DISCOVERED IN 1958, STILL MYSTERIOUS

Explorer 1, 1958

Time Magazine, May 4, 1959


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.


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


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)


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


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


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


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


ELFIN’s Systems Engineering Processes

Shin Yamamoto


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


ELFIN’s Systems Engineering Team works on

Requirements management and V&V

Resource management

Interface management

Project document lists

Technical evaluations

SYSTEMS ENGINEERING MANAGEMENT


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


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


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



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:



An MRD is used to organize the flowdown traceability of every requirement



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




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


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



Budget Owner Team

Mass, Pointing Anais Zarifian Systems

Power Shin Yamamoto Systems

Link Kyle Colton Communications

Data Lydia Bingley Operations

RESOURCE MANAGEMENT


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


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


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


ENGINEERING DOCUMENT LIST


MASTER EQUIPMENT LIST


MATERIALS LIST


CABLES LIST


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


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



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.



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.



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.



Questions?

SYSTEMS ENGINEERING


MISSION REQUIREMENTS

Mission Requirements

John



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




MSN-03 ELFIN shall deorbit within 25 years from the conclusion of the mission

Constraint levied by government regulations to prevent “space junk”


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





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



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



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




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



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


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





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


SYSTEM REQUIREMENTS


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.


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.


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.


MSN-11 A: Solidworks simulation


SYSTEM REQUIREMENTS


SYS-05 The CubeSat shall be designed to accommodate ascent venting per ventable volume/area < 2000 inches.


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.


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.


SYSTEM REQUIREMENTS


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.



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


SYSTEM REQUIREMENTS


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)


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


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.



SYS-16 ELFIN shall use materials that comply with NASA-STD-6016


NASA-STD-6016 I: Inspection of Engineering and Flight Model


SYSTEM REQUIREMENTS


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


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


SYSTEM REQUIREMENTS


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


SYSTEM REQUIREMENTS


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


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



SYSTEM REQUIREMENTS


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


FGM REQUIREMENTS

FGM Requirements

Kathryn


FGM REQUIREMENTS


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



PLD-24 The FGM shall have a relative stability of 1 nT/2 hr Stability required by Science



PLD-25 The FGM shall have a noise level of 0.5 nT/sqrt(Hz) Noise level required by Sciece



PLD-27 The FGM shall have a digitization of > 20 bits Resolution required by Science


PLD-28 The orthogonality of the FGM sensor shall be known to <= 5 degrees

Needed to find the pitch angle distribution



PLD-29 The FGM sampling rate shall exceed DC-5Hz Needed to find EMIC waves which are 1-2Hz



EPD REQUIREMENTS

EPD Requirements

Maxwell Chung


DETECTOR STACK DESIGN EPD-E


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


DETECTOR STACK DESIGN EPD-I


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


MECHANICAL DESIGN


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)


MECHANICAL DESIGN


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)


SOFTWARE DESIGN


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


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


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.


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


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.


IDPU REQUIREMENTS

IDPU Requirements

Pat


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


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:


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


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)


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


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)


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


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


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.


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


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.


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


Electron Losses and Fields Investigation

System Requirements Review

Switching Instrument Power Supply (SIPS)

Ryan Caron

Los Angeles, California

February 8th, 2015


EXPLODED VIEW


SIMPLIFIED POWER TOPOLOGY


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


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


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%


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


~ 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


ADCS REQUIREMENTS

ADCS Requirements

Oliver


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


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


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


ADCS REQUIREMENTS


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



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


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


C&DH-04 C&DH shall be capable of disabling the spacecraft communication system on command from the ground station

Requirement from FCC


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



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


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


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


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


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


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



C&DH REQUIREMENTS

C&DH-12 All software shall support a sleep-wake cycle Saves power


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


C&DH-14 All software must be tolerant to single event upsets. (SEUs)

Ensure that the software is radiation tolerant


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


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




COMM Subsystem

Requirements

Kyle Colton



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


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


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


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


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 Review

Electrical Power Subsystem

Akshaya Subramanian

Los Angeles, California February 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




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




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




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


STRUCTURES & MECH REQUIREMENTS

Structures and Mechanisms

Chris Yu


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,


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,


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.



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,


STRC-15 The center of gravity shall be located within 2 cm from its geometric center in the X and Y directions


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


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


THERMAL REQUIREMENTS

Thermal Requirements

Chris Knapp




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.





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.




ESN Subsystem Requirements

Kyle Colton



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.


unforeseen losses.



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


unforeseen losses.



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



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



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


OPERATIONS REQUIREMENTS

Mission Operations

Lydia Bingley


• 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


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


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.]



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]



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


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


EGSE REQUIREMENTS

I&T: Electrical Ground Support Equipment

Requirements Michael Anderson


EGSE REQUIREMENTS


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.



I: by design

GSE-03 Electrical Ground Support Equipment shall be capable of powering the satellite while the satellite is inhibited.



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


I: by design


EGSE REQUIREMENTS


GSE-05 Electrical Ground Support Equipment shall be self-contained and portable.

So we can take GSE to the integrator


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


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


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


I: by design


EGSE REQUIREMENTS


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


I: by design

GSE-10 The main power switch shall be provided with an indicator light. To avoid damaging

the equipment


I: by design

GSE-11 All Electrical Ground Support Equipment switches or buttons shall be clearly labeled. To avoid damaging

the equipment


I: by design

GSE-12 Circuit protection shall be installed on primary circuits, on the load lines. To avoid damaging

the equipment


I: by design


EGSE REQUIREMENTS


GSE-13 Circuit protection devices shall be readily accessible for inspection, reset, or replacement. To avoid damaging

the equipment


I: by design

GSE-14 Circuit protection shall be clearly marked with voltage present and rated amperage. To avoid damaging

the equipment


I: by design

GSE-15 All wiring shall be copper. To mitigate thermal cycling stress


I: by design

GSE-16 Wiring and contact materials shall be chosen such that electrical interfaces do not oxidize.

Connector reliability


I: by design

GSE-17 Aluminum wire shall not be used. To mitigate thermal cycling stress


I: by design


EGSE REQUIREMENTS


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


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.


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


I: by design


EGSE REQUIREMENTS


GSE-21 Equipment shall be designed, fabricated, inspected, and tested in accordance with NFPA 70.

Follow National standards for electrical safety


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


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


I: by design

Electron Losses and Fields Investigation (ELFIN)...2015/02/08 · ELFIN shall measure the storm-...

Documents

Transcript of Electron Losses and Fields Investigation (ELFIN)...2015/02/08 · ELFIN shall measure the storm-...