Nostalgic ?

• 1 - Introduction • 2 - Propulsion & ∆V • 3 - Attitude Control & instruments • 4 - Orbits

& Orbit Determination

• 5 - Launch Vehicles • 6 - Power & Mechanisms • 8 - Reliability • 9 - Reliability, Management • • 10 - Thermal

11 -

Thermal / Mechanical Design. FEA

(Joel Pedlikin) •

12 - Management, Cost & Schedule, Digital

•

13 - Design workshop / AeroAstro support

(4/25)

• 14 - Presentations

(4/30)

Due Tonight, April 18

• Draft presentations Engineering 176 Meeting #12

Due Thursday, April 25

Engineering 176 Meeting #12

• Therapy for presentations • Update on Projects

Burglar Alarm Paradox: update

Burglar Alarm Reliability: 99.9% • False alarm happens 1:365 days (1 per year) Chance of being robbed: 1: 10,000 houses (or cars) /yr P(alarm goes off due to robbery): Assume alarm sounds: P(Robbery) = 0.0001

P (False) = 0.00275

=> P(False) / P(Robbery) = 0.00275 / 0.0001 = 27.5 : 1 ->27.5 false alarms for every real robbery < If Alarm lives 10 years and false alarm costs $100: Cost = $100 x 1 x 10 + $(buy and keep alarm) = $1000 + ($250 + $10 x 12 x 10) = $2450 = Cost Expected Value of Alarm = 0.0001 x 10 x uninsured deductible (maybe $25k) =

Engineering 176 Meeting #12

$25 = EV

If life is a banquet...

• • • • • •

Mission Definition

– Black tie & prime rib for 300 at the Ritz vs. – Beer and hot dogs in the park down the street

Preliminary Design

– Select entré, drinks, desert, type of music => 1st serious cost estimates

Detailed Design

– # bottles of Schlitz / Perrier & Jouet, ft2 of cake, place markers, # of beef => may sign up to fixed price

ICD

– Cash bar? Who supplies the flowers? (Flowers? What flowers?). Chairs?

Management and Standards

– Waiters in tuxedos, sommelier and served hors d’ouvres vs. buffet

Build vs. Buy

– Can you really bake those cookies for less than $7/lb? (and so what!) – What won’t get done while you’re busy at home baking? Engineering 176 Meeting #12

What “Management” Does

• Planning and Predicting: – What can be done at what budget – How many people of what types for what duration necessary to do a job – Translate that into contracts, deliverables, payment schedules and then constantly reworking them as the program evolves • Creating the environment – Tools, desks, support staff, purchasing, quality, inspection – Compensation, staffing, benefits, incentives, job descriptions and interrelations – Understanding the client’s / application’s requirements • Measurement and Intervention – Program revues and other milestones – Employee assessment, assignments – Doing something when it isn’t working • Problem solving – Supposedly you have those grey hairs for a reason – Picking significant problems out of the noise of day-to-day issues (don’t do other people’s jobs for them) – Mediating among teams and between team and clients / suppliers • Getting the job done via your staff – Deadlines and standards / program meetings / team building / – Communicating between suppliers (us) and consumers (them)

What “Upper Management” Does

• Tech Management: CTO – Technical accuracy, quality (no errors + state of the art) – Yellow flags: coming disruptions (and opportunities), dead-end approaches – Innovating new solutions: make the company more technical competitive – Management of the tech staff - “what about me?” • Corporate Management: COO – Legal: employees, workplace, contracting / auditing, patents – Finding inefficiencies and stomping on them – Physical Plant: leases (space and equipment) – Contracting and negotiating • Finance Management: CFO – Business plans and money raising – Cash management – Lease v. buy, investing short / medium term • VP Biz Dev: – Bid / No-bid, proposal prep – Marketing, advertising, trade shows corp persona – Dabble in programs • success is your most powerful sales tool • Ongoing client relationships • CEO – Why are we here • Define our biz niche • New directions • Growth (or no-growth) • True to our roots?: corp. memory – Corporate philosophy • Look and feel – Employee relations – Contracting style and – Strategy client select – Who works here • Relationships • Person behind the curtain • Mergers / Acquisitions – Ambassador (icon) – Rep. to the board – + Per CEO’s strengths

Engineering 176 Meeting #12

Engineering 176 Meeting #12

Program Life Cycle

Engineering 176 Meeting #12

Order Component

• Development is a learning process. • Planning is no substitute for actual experience:

The important thing is the Planning, not the Plan

• Everything is negotiable.

• Will you build > 1 satellite in your life?

The Dilbert Wars Management vs. Engineering

Engineering 176 Meeting #12

•

Documentation

Basic Rule: Don’t write what no one will read.

•

Go for easy documentation:

– – –

Email exchanges Manufacturer’s data on purchased parts Videos of procedures - Photographs of everything - Test & failure logs - Well documented code

•

Offer automatic documentation

–

Fabrication drawings & schematic diagrams - Block diagrams

•

Synthesized documents worth producing

–

ICDs - System Requirements Documents

– – – –

(H&S’wr) Cabling diagram Users’ manual Contracts, change orders etc.

- Launch environment - Thermal / Structure analysis reports - Test plans & results

Engineering 176 Meeting #12

• • • •

Operations at a minimum

GS Locations:

(arranged by cost impact) – Central GS: Their motivation vs. yours; Labor intensive; Capability exceeds needs.

– Field GS: Portable, hardened equipment; Virtually always backed up at office; Minimal Autonomy but must be idiot and disaster proof.

– Remote GS: Similar to Office but: rent; person to power cycle, maintain, trouble shoot; max investment in environmental protection (radome, foundation, heater / AC, backups) – Office GS: Motivates autonomy; Employ existing staff; Already on your network – No GS: per minute charges only

GS Staffing

– First 30days: Engineering staff: some (˜3) present, some on call (˜everyone), frequent telecon and in person briefings; don’t forget your PR staff – Day 31 to day 90: Engineering (1 or 2) and Ops staff (2 or 3): transition; anomaly track.

– Ongoing: Ops staff: One person plus buddy plus on-call. Engineering staff on board via email and occasional reviews. Probable budget for capabilities upgrades. Possible savings by GS sharing (multiple antennas or prioritize)

Software

– Autonomy and anomalies • Autonomy is not a risk it’s a reliability plus – down time (LANL fire experience) – Menu selection vs. freehand composition

Tracking

– Role & limitations of GPS – Role & limitations of Cheyenne • •

The no GS GS

– Geosynchs – LEO commsat links – Receive only GS

Managing the Remote GS

– Site availability, installation & test – On-site maintenance – Visits for • Upgrades • Alignment and maintenance Engineering 176 Meeting #12

Keeping Ops Cost Down

• • • • • •

Design-in Autonomy

– Satellites go by at the oddest times...- beepers – Design must tolerate outages gracefully (to lower the cost of a GS failure) – Intuitive, graphic, quick-look, menu driven interfaces

Simple GS

– Rental and staffing costs will exceed spacecraft costs – Office / lab space is never free - for long – Pick an orbit that passes over your office

Assume a 6 month mission Manage the transition

from the development team to the ops team – Don’t break things and then have to fix them – Allow several months overlap - Agree on command authorization levels

Keep the development team plugged in

– i.e. via email for rapid anomaly resolution

Use the internet

– Remote control vs. remote personnel (if you need a remote GS at all) – Use dial up for security – Find hosts to attend the GS in exchange for data / service access Engineering 176 Meeting #12

Populating your program

Engineering 176 Meeting #12

Scheduling Your Program

Engineering 176 Meeting #12

Issues with Space Processors

• • • •

Expensive as they are, and even more expensive to customize

– – –

Additional hardware required to talk to your devices May drive design of other subsystems - potentially inefficient designs e.g. Aux Bus, readout frequency requirements, Not produced & used in quantity => no large investment or test

– –

development environments often buggy, costly, not widely supported Note: 68020 and 80C81 are “easy” because market has invested $billions in them Large, heavy, high power

– – –

lack of custom, highly integrated components most efficient components don’t come in “space qual” (e.g. they’re plastic) probably developed for larger missions where these features are less critical Less processing gazorch

– – – –

Coding at low level required - adds cost, decreases reliability Software writers will tend to be specialists not familiar with spacecraft May require multiple processors (more mass, power, risk) May encourage solving problems in hardware (e.g. attitude solutions)

Engineering 176 Meeting #12

Space Environment Survival

• • •

0-g

–

doesn’t matter Vacuum

–

check electrolytics, on-board battery, plastic outgassing Thermal

–

Copper backplane and/or processor-mounted radiator

– –

Isolated, high-dissipation parts must be heat-sinked Temperature range adequate?

•

Vibration / Shock

–

normally not an issue - may need to stake connectors (launch loads are trivial compared with most consumer apps.)

•

Autonomy

–

watchdog timers, multiple copies of on-board RAM and ROM

•

Radiation Tolerance

–

SEU / Latchup / Total Dose

Engineering 176 Meeting #12

•

Selecting Your Processor*

Not a harmonious process

– Strong individual opinions ( “ religion ” impossible) - like Macs vs. PCs, - compromise – Huge # of candidates to choose among – Program-wide impact - everyone gets in the act – Everyone thinks they know something about it – Disinformation was invented for the processor world – vapor hardware, vapor software, capability overstatement – never admit a bug exists - even after numerous customer complaints •

• Some Suggestions

– Scrutinize hardware availability and support tools – Believe NO predicted delivery or availability dates for new products – Create, in advance, a mutually agreed evaluation matrix including: – speed (determine what ’ s required) – radiation (what ’ s really required) – development environments and platforms – compatibility with existing software / hardware – extra features - these are a liability, not a plus - electric power - other required features Engineering 176 Meeting #12

*Adapted from thoughts of Jan King, past-president, AMSAT-NA

•

Centralized Processing

and “King’s Funnel ” Pros:

– Single µ P: simple architecture – Central multitasking well understood – Single state machine => easier testing •

Cons:

– “ King ’ s Funnel ” (below) – Fast enough for multitask or no interrupt?

– Interrupt may be overwhelmed • – µ P is single point of failure

King ’ s Funnel Ingredients:

– Software not complete at time of integration – System bugs start affecting program mostly requiring software resolution – Hardware and firmware / controller developers can ’ t help much – Lone Ranger has long ago intimidated or demotivated all others & is only one left who can operate spacecraft •

=> Program will wait for Lone Ranger to emerge from Funnel

Engineering 176 Meeting #12

Distributed Processing

•

Pros:

–

Eliminate King’s Funnel (questionable)

–

Eliminate single point failures (also questionable)

–

Lots of horsepower

•

Cons:

–

Latest and Greatest thing =>

• • •

poor heritage selected for sex appeal?

pay for team ’ s education

–

Multiple state machines

• •

hard to test / verify state crash prone

–

May still suffer:

• • •

intercept overload King ’ s Funnel single point failure (since many multi-processor systems are actually hub & spoke)

–

Lots more electric power

Engineering 176 Meeting #12

•

Features You Will Need

Reliability:

– Watchdog timer – Multiple systems with toggle / voting – On-board EDAC – Self-booting – Hard O/S copy – Multiple copies of O/S and applications – State saving (e.g. flash RAM) • •

Compatibility:

– Mechanical strength and robustness – Thermal margin / heat sinking – Adequate I/O interfaces – Instrumentable

Programmatic:

– Afford multiple copies (normal for us has been 15 to 20) – good, widely used development and support systems – Sufficient gazorch to enable high level coding and easy debugging Engineering 176 Meeting #12

Engineering 176 Meeting #12

ALEXIS Block Diagram

• • •

Single 80C86 (commercial, plastic)

–

Clocked at 4 MHz

–

A and B sides

•

Tested after 9 years on orbit Modeled on PC backplane: Components treated as “ plug in cards ”

– ACS – Power controller – Housekeeping sensors – Memory – Tx / Rx Payload interface via dual port RAM – Easy to simulate – Excellent isolation – Quasi multi-processor (payload has its own to deliver bits to DPR)

A whole page on code uplinking

•

Pros:

– Allow late (post-launch) implementation of upgrades • may save program schedule!

•

Cons:

– Encourages continuous creation of upgrades • may destroy program schedule!

– Can run off uplinked code if native controller has significant fault – Demotivates testing to find and squash bugs in controller – Allows work-arounds for in flight failures and aging effects – Additional complication in overall system design – Increase autonomy as system is learned and confidence gained Engineering 176 Meeting #12

HETE / TERRIERS Processor

Engineering 176 Meeting #12

HETE Processor Highlights

•

•

Three distinct processor sections: Transputer, DSP0, DSP1.

Transputer networked to other Transputers =>board-level redundancy Runs spacecraft housekeeping: power management, attitude control, etc.

• •

•

DSP1 runs science code fast at low power.

DSP0 manages spacecraft bus

2 W, no space qual parts, all plastic, commercial data bus (Nubus) interface, 30 MIPS

Engineering 176 Meeting #12

Course Goals

•

•

•

•

• •

The Design Process: Augenblick of a higher level of complexity

•

Aerospace Engineering: An application of engineering sciences

Using Analysis and Design Tools

Working on something too big to even think about doing yourself - Teams Systems Engineering: Optimize around solutions

Design and build something, and present it

See yourself 5, 10, 15, 20 years from now

Engineering 176 Meeting #12

Last slide

•

Why you should / shouldn’t go further with aerospace / space engineering

•

Does your field matter?

•

Does engineering matter?

Engineering 176 Meeting #12