Post on 25-Dec-2015
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
Engineering 176 Meeting #12
Due Tonight, April 18
• Draft presentations
Engineering 176 Meeting #12
Due Thursday, April 25
• Therapy for presentations
• Update on Projects
Engineering 176 Meeting #12
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
Engineering 176 Meeting #12
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)
Engineering 176 Meeting #12
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
Engineering 176 Meeting #12
Engineering 176 Meeting #12
Engineering 176 Meeting #12
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
Engineering 176 Meeting #12
The Dilbert WarsManagement vs. Engineering
Engineering 176 Meeting #12
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.
Engineering 176 Meeting #12
• 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
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” - 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
Engineering 176 Meeting #12
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)
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
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)
Engineering 176 Meeting #12
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
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 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
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?