engineering 176 meeting #12 nostalgic ? 8 - reliability 9 - reliability, management 10 - thermal 11...

Engineering 176 Meeting #12

Nostalgic? • 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)

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

& instruments• 4 - Orbits

& Orbit Determination

• 5 - Launch Vehicles• 6 - Power

& Mechanisms• 7 - Radio & Comms


Due Tonight, April 18

• Draft presentations


Due Thursday, April 25

• Therapy for presentations

• Update on Projects


Burglar Alarm Paradox: updateBurglar 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) = $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?


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 client select– Who works here

– Strategy• Relationships• Person behind the

curtain• Mergers / Acquisitions

– Ambassador (icon)– Rep. to the board– + Per CEO’s strengths


Program Life Cycle

• 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?

Requirements Synthesis

Preliminary Design

Detailed Design

Fabrication

Test &Integration

Development is a poly-cyclic

process. Each phase of the process is

cyclic with the ones adjacent

to it.

Order Component


The Dilbert WarsManagement vs. Engineering


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

• Go for easy documentation:– Email exchanges - Photographs of everything– Manufacturer’s data on purchased parts - Test & failure logs– Videos of procedures - Well documented code

• Offer automatic documentation– Fabrication drawings & schematic diagrams - Block diagrams

• Synthesized documents worth producing– ICDs - System Requirements Documents

– (H&S’wr) - Launch environment

– Cabling diagram - Thermal / Structure analysis reports

– Users’ manual - Test plans & results

– Contracts, change orders etc.


• 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

Operations at a minimum

• 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


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


Populating your program


Scheduling Your Program


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)


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


Selecting Your Processor*• Not a harmonious process

– Strong individual opinions (“religion” - like Macs vs. PCs, - compromise impossible)

– 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) - electric power– radiation (what’s really required) - other required

features– development environments and platforms– compatibility with existing software / hardware– extra features - these are a liability, not a plus

*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

systemintegration

Lone ranger software engineer

Spacecraft Hardware

Developed code

Bad things happen here

And lots of time passes

One Functional Spacecraft

(very late)


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


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


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!

– Can run off uplinked code if native controller has significant fault

– Allows work-arounds for in-flight failures and aging effects

– Increase autonomy as system is learned and confidence gained

• Cons: – Encourages

continuous creation of upgrades

• may destroy program schedule!

– Demotivates testing to find and squash bugs in controller

– Additional complication in overall system design


HETE / TERRIERS Processor


HETE Processor Highlights

• Three distinct processor sections: Transputer, DSP0, DSP1.

• Transputer networked to other Transputers =>board-level redundancyRuns 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


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


Last slide

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

• Does your field matter?

• Does engineering matter?