Space Engineering 2
Lecture 1
1
Space Engineering 2 © Dr. X Wu, 2008
Literature
 James R. Wertz and Wiley J. Larson,
Space Mission Analysis and Design
(SMAD), 3rd Edition, EI Segundo, CA,
Microcosm Press, 1999.
 Peter Fortescue, Spacecraft Systems
Engineering, 3rd Edition, Wiley, 2003.
2
Space Engineering 2 © Dr. X Wu, 2008
Objectives
 Knowledge of systems engineering aspects of
designing spacecraft.
 Knowledge of the Space Environment & its Effects.
 Knowledge of Spacecraft Bus Subsystems & Design;
 Ability to perform Space Mission Analysis & Design;
 Document the design process in sufficient detail that
another engineer can continue on with the work just
by going through the log book.
3
Space Engineering 2 © Dr. X Wu, 2008
Last Year’s CubeSat Designs
4
Space Engineering 2 © Dr. X Wu, 2008
Presentations & Labs
 Presentations
 Preliminary Design Review (5%)
 Critical Design Review and Test (5%)
 Labs
 ADCS on Airbearing table (10%)
Nanosatellite Fundamentals
”The Design Space”
Dr. Xiaofeng Wu
Future Space Engineering
 Trends in Future Spacecraft
 Miniaturized
 Autonomous and intelligent
 Distributed
PCBSat
CubeSat
PICOSat
1-100g
0.1–1kg
1-10kg
10-100kg
100-500kg
£100-1000
£10-100K
£1-2M
£1-10M
£10-50M
Femtosatellite
Picosatellite
Nanosatellite
Microsatellite
Minisatellite
ChipSat

PalmSat
Snap-1
 Application Domain




Remote monitoring, diagnostics and self-repair
Co-orbiting assistants/inspectors of larger spacecraft
Virtual satellite missions
Interplanetary applications
UK-DMC
Selected Nanosatellite Topics
 Introduction
 What is a
Picosatellite
 History of Missions
 Proposed Missions
 Basic Design
Space
 More?
 Supporting
Technology
 Constellation
design
 Intersatellite Links
 Reconfigurable
computing
 Distributed
processing
 More?
What is a Picosatellite
 Mass less than 1 kg,
larger than 100g
 Typically on the order of
10 cm3 volume
 At the edge of
technology for
 Meaningful downlink
 Single-sat constellation
 Well suited for

“Distributed Satellite
Missions”
Minisatellite
Microsatellite
Nanosatellite
Picosatellite
Femtosatellite
100 - 500 kg
10 - 100 kg
1 - 10 kg
100 g - 1 kg
1 - 100 g
History of Missions

Not to be confused with illnamed USAF mission
“PICOSat” (SSTL sat)
OPAL 2000



Eurockot Launch 2003



2 of 6 successful
Each custom designed
3 of 5 successful
All “CubeSat” bus types
(Stanford/Cal Poly standard)
SSETI Express 2005


2 of 3 successful
Again, all “CubeSats”
1.5
1
Mass (kg)

0.5
0
1999
2001
2003
2005
Proposed missions
 Several Nanosats in the works, watch
for:
 Micro-Link 1, Ångström Aerospace,
Swedish & Canadian joint-effort targeting
mass-production
 Recent Picosat concepts proposed
 PalmSat (SSC)
 More CubeSats


Japan, others
Website advertises 40+ current universities
 Others?
Picosat Design Space
Notional Mass/Power Budget
Mass Mass
Power
Power
Subsystem (g) Budget (mW)
Budget
Payload
244
24%
480
40%
Structure
227
23%
EPS
246
25%
240
20%
DH
65
7%
120
10%
Comm
65
7%
360
30%
ADCS
130
13%
?
Thermal
20
2%
?
Total
1000 100%
1200
100%
- Problem Areas 



Single-sat missions virtually useless,
except for education
Low power budget
Low data rate downlink
No room for conventional propulsion
Electrical Power Subsystem
Body-mounted cells
Average Power Budget in mW
NiCd Battery mass < 50g
Sun/Ecl Sun Only
14.8% Si
650
1100
18.5% GaAs
800
1400
28.0% GaAs 1200 mW
2100
Comm Link Budget
2.4 GHZ 802.11
12 cm 1-lambda antennas
10 dB Margin, 10% Power/RF Conv. Eff.
100 mW
Data Rate (10 mW RF)
19.2 kbps 7 km
1 Mbps
1 km
54 Mbps 100 m
1W
(100 mW RF)
25 km
3 km
400 m
PC-104 COTS Picosatellite Concept
 PC104 COTS standard
 150+ vendors
 Many types available
 Focused on rugged
Military/Embedded apps
 5-module stack
 For rapid prototyping
 10 cm3 volume, ~1 Kg
 Start with 3 COTS modules:

FPGA, Wireless, GPS
 Add custom Payload, EPS,
AOCS, TCS
COTS pico-satellite design
Shown: Qualified OBC (MSP430) / FPGA (Xilinx Virtex4) /
Communications (Elcard 802.11 Wireless Board) / Qualified EPS (Clyde
Space) / Structure by CubeSat Kit
CubeSat Components
 Structure
 Command & Data Handling with highfrequency transceiver and antennas
 Communications (COM)
 Electrical Power System (EPS)
 Solar Cells
 Attitude Determination & Control System
(ADCS)
 Payload
CubeSat Developed at SSC
PhoneSat
PhoneSat 1: System Architecture
Phone
(Nexus One)
UHF Radio
440 MHz
Spacecraft 1.0
Concept A
•With UHF radio
•& Hardware battery override
•& Watchdog/Lazerus
Watchdog/
Lazerus
(Arduino)
Legend
Custom PCB
Monopole
Antenna
Battery Bank
(12 x 18650 3.7V
cells, 2800 mAh)
Core
Likely
Core
Extra
Power
Data
Why use a phone?
 Increase on-orbit processor capability by
a factor of 10-100
 Decrease cost by a factor of 10-1000
 Free up cubesat volume for additional
payload through avionics miniaturization
 Demonstrate COTS approaches to all
subsystems (ie, power, RCS, comms)
Produce high-capability spacecraft for $110k (exc. LV)
Nexus One
•Android OS
•1 GHz Processor
•500 MB RAM
•16GB Data Storage
•3-axis accelerometer, 3-axis magnetometer
•5MP Camera/VGA Video Camera
•GSM, WiFi, Bluetooth, FM radio
•GPS (restricted)
PalmSat
Satellite-on-a-PCB (PCBSat)



Dimension: 9x9.5cm, compatible with PC104 form factor
Mass: ~200g
Power: 650mW peak
Satellite-on-a-Chip (ChipSat)
RF Comm
on a chip
(<1 km range)
It’s possible, but:
Mission utility is
main issue—too small
(heat sink)
(<1% eff.)
(radiation)
Attitude/
Orbit
Control
Thermal
Control
Solar selfpowered
Data
Handling
(2-sided)
(no propulsion)
Configuration:
CMOS, <10g, 20x20x3 mm
(largest die possible)
CMOS
imager
(lens)
Possible Missions for CubeSat
 Distributed computing
 Pico-satellite constellation
 Formation flying
 On-board signal processing




Optical signal
Radar signal
Electromagnetic signal
Thermal signal
 Possible Missions
 Communication

Global communication for handheld terminals.
– Little LEO systems: ORBCOMM constellation

Semantic web service
– The Web, once solely a repository for text and
images, is evolving into a provider of services—
information-providing services, such as flight
information providers, temperature sensors, and
cameras, and world-altering services, such as
flight-booking programs, sensor controllers, and a
variety of e-commerce and business-to-business
applications
– Grid computing on satellite constellation using the
on-board computers to provide prompt web
services
 Space Weather Monitoring



Adverse conditions on the Sun in the Solar Wind and in
the Earth’s magnetosphere, ionosphere and
thermosphere
Influence the performance and reliability of spaceborne and ground-based systems and endanger
human life or health.
Space weather sensors
–
–
–
–
Telescope: improve the observation capabilities.
Special Sensor Ultraviolet Limb Imager (SSULI):
measure the natural airglow radiation from atoms,
molecules and ions in the upper atmosphere.
Special Sensor Ultraviolet Spectrographic Imager
(SSUSI): measure ultraviolet emissions in five different
wavelength bands from the upper atmosphere.
Solar X-Ray Imager (SXI): provide x-ray imagery of the
disk and corona of the sun.
 Earth observing

Disaster monitoring
– DMC constellation: 5 micro-satellites in LEO, optical
imaging payload
– Optical sensing: fire, flood
– Electromagnetic sensing: earthquake (QuakeSat)
– Radar imaging
– On-board signal processing
» Encryption
» Data compression
» Intelligent on-board signal analysis and
decision making
Formation Flying Concept
NASA Terrestrial Planet Finder (TPF): Planet
search and imaging
TS3: links separate telescopes together to
produce one large image.
TechSat-21: Autonomous Agent Experiment
(Project cancelled due to complexity of problem
and budget overruns)
NASA Ants Framework: Reconfigurable
Computing, Autonomy, MEMs instruments for
Distributed Space Missions
What is a Space System

Ground




Space



Spaceflight Operations
Payload Operations
Payload Data Processing
Orbits
Spacecraft
Launch


Launch Vehicle Integration
Launch Operations
30
Space Engineering 2 © Dr. X Wu, 2014
Ground

Ground Activities:





Spacecraft Flight
Operations
Payload Operations
Payload Data Processing
Payload Data
Dissemination
Can Be
Merged
Facilitated By:




Real-Time Processing
Payload Dissemination
Infrastructure
Powerful Payload
Processing Facilities
Mission Simulations
31
Space Engineering 2 © Dr. X Wu, 2014
Launch
 Selection:




Enough “throw weight”
Enough “cube” (volume)
Acceptable ride
Good record…
 Integration:


Launch loads imparted
to spacecraft
Mechanical/Electrical
Integration
32
Space Engineering 2 © Dr. X Wu, 2014
Space Mission Architecture
33
Space Engineering 2 © Dr. X Wu, 2014
Payloads and Missions
Mission
Trajectory type
Communications
Geostationary for low latitudes, Molniya and Tundra
for high latitudes (mainly Russian), Constellation of
polar LEON satellites for global coverage
Earth Resources
Polar LEO for global coverage
Weather
Polar LEO, or geostationary
Navigation
Inclined MEO for global coverage
Astronomy
LEO, HEO, GEO and ‘orbits’ around Lagrange points
Space Environment
Various
Military
Various, but mainly Polar LEO for global coverage
Space Stations
LEO
Technology Demonstration
Various
Note: GEO – Geostationary Earth Orbit; HEO – Highly Elliptical Orbit; LEO – Low
Earth Orbit; MEO – Medium height Earth Orbit
34
Space Engineering 2 © Dr. X Wu, 2013
Objectives and Requirements of a
Space Mission
35
Space Engineering 2 © Dr. X Wu, 2013
Space System Development




All systems development start with a “mission need” (the
Why)
Then mission requirements are developed to meet this need
(the What) often along with a concept of operations
Note: Often we make the mistake of putting “the How”
in the Mission Requirement
From 1 and 2 above develop derived requirements for (the
How):

Space




Ground





Mission orbit
Payload Types (Communications, remote sensing, data relay)
Spacecraft Design
Facilities and locations
Computers/Software
Personnel/Training
Launch segments
Note: The requirements generation process is often iterative
and involves compromises
36
Space Engineering 2 © Dr. X Wu, 2013
Requirements of a Spacecraft
1.
2.
3.
4.
5.
6.
7.
The payload must be pointed in the correct
direction
The payload must be operable
The data from the payload must be communicated
to the ground
The desired orbit for the mission must be
maintained
The payload must be held together, and on to the
platform on which it is mounted
The payload must operate and be reliable over
some specified period
All energy resource must be provided to enable the
above functions to be performed
37
Space Engineering 2 © Dr. X Wu, 2013
Spacecraft Subsystems
Space Segment
Payload
Bus
Structure
Attitude and
orbit control
Power
Thermal
Telemetry and
command
Propulsion
Data
handling
Mechanisms
38
Space Engineering 2 © Dr. X Wu, 2013
Spacecraft Description

Spacecraft have two main parts:



Mission Payload




Mission Payload
Spacecraft Bus
A subsystem of the spacecraft that performs the actual mission
(communications, remote sensing etc.)
All hardware, software, tele- communications of payload data
and/or telemetry and command
There can be secondary payloads
Spacecraft Bus
Hardware & software designed to support the Mission Payload

Provides





Power
Temperature control
Structural support
Guidance, Navigation & Control
May provide for telemetry and command control for the payload
as well as the vehicle bus
39
Space Engineering 2 © Dr. X Wu, 2013
Spacecraft Development Process



Some types:

Waterfall (sequential)

Spiral (iterative)
Basic Sequence:
1. Conceptual design
2.
Detailed design
3.
Develop detailed engineering
models
4.
Start production
5. Field system
6.
Maintain until decommissioned
DoD mandates integrated, iterative
product development process
Requirements
Development
Detailed
Design
Engineering
Development
&
Production
Field
(IOC)
40
Space Engineering 2 © Dr. X Wu, 2013
Serial (waterfall) Development
1. Traditional “waterfall” development
process follows logical sequence
from requirements analysis to
operations.
2. Is generally the only way to develop
very large scale systems like
weapons, aircraft and spacecraft.
3. Allows full application of systems
engineering from component levels
through system levels.
4. Suffers from several disadvantages:
•
•
•
Obsolescence of technology (and
sometimes need!)
Lack of customer
involvement/feedback
Difficult to adjust design as program
proceeds
http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/07.13.SWEng1/html/text.html
41
Space Engineering 2 © Dr. X Wu, 2013
Spiral Development
Software Development Centric Example
Good features
1.
2.
3.
4.
In this approach, the entire application is built
working with the user.
Any gaps in requirements are identified as work
progresses into more detail.
The process is continued until the code is finally
accepted.
The spiral does convey very clearly the cyclic
nature of the process and the project life span.
Not so good features
1.
2.
3.
4.
This approach requires serious discipline on the
part of the users. The user must provide
meaningful realistic feedback.
The users are often not responsible for the
schedule and budget so control can be difficult.
The model depicts four cycles. How many is
enough to get the product right?
It may be cost prohibitive to “tweak” the product
forever.
Simply put: Build a little – Test a little!
Can this work for every type of project?
From: http://www.maxwideman.com/papers/linearity/spiral.htm
And Barry Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer, 1988
42
Space Engineering 2 © Dr. X Wu, 2013
System Development Process

‘Breadboard’ system


Prototype



First draft of complete system
Implements all requirements
Engineering model



Concept development and proof of concept
Complete system without final flight configuration
Plug and play with flight model
Flight model


The final product
Space-ready product, implements all requirements
Design Review

Preliminary Design Review (PDR)





Architecture and interface specifications
Software design
Development, integration, verification test plans
Breadboard
Critical Design Review (CDR)







System Architecture
Mechanical Design Elements
Electrical Design Elements
Software Design Elements
Integration Plan
Verification and Test Plan
Project Management Plan
Spacecraft Integration and Test


Methodical process for test of
spacecraft to validate requirements
at all levels
Sequence:
1. Perform component or unit
level tests
2. Integrate components/units into
subsystems
3. Perform subsystem tests
4. Integrate subsystems into
spacecraft
5. Perform spacecraft level test
6. Integrate spacecraft into system
7. Perform system test when
practical