Decomposition: Interfaces & Alternatives

1. EMIS 8340 Systems Engineering Tool—applying tools to engineering systems Decomposition: Interfaces & Alternatives Mark E. Sampson

2. Remember External Interfaces… • Captured during project scopeing… • What do you have to interface with in the outside world? …these are the stimulus & recipient of our system. • Applications Study: Henry Ford’s first car and Explorer Tire Recall • Upon completion of his first automobile in his workshop, Henry Ford was amazed to discover it didn't fit through the door (Henry Ford, p.30, A. Knopf, 1966) • …or a more recent example from the news… • May 20, 2001--Ford Motor Co. is recalling 50,000 brand new Explorers because an assembly line conveyor belt that was too narrow for the wider 2002 model may have cut the tire tread (http://abcnews.go.com/sections/us/DailyNews/tires_recall_wire010520.html) [SE Handbook 4.1] [Hooks 2001]

3. External Interfaces… Test Equipment Storage Software Printer EMI Networks Power People Be sure to ask the question, “What is the worst thing otherelements could do to you across this interface?” [Kuchta, 1989] …and defend against it! [Hooks 1999] [Lacy 1992] [Hooks 2001]

4. Func 3 Func 1 Func 4 Func 2 • Internal Interfaces… • Developing functional interfaces… • Each function requires an input to operate (goes’intos) • Each function produces an output (goes’outofs) • Identify & document what & how eachfunction will obtain its input and where it will send its outputs • Tools help capture & keep up with these interfaces—SE tools like: • Popkin SA, Cradle-SEE, CORE,SLATE,…SW Modeling tools like: • Artemus, Describe, Rational, Tau,… [SE Handbook 9.2] [DMSC 1986]

5. Func 2.1 Func 2.3 Func 2.2 Func 3 Func 1 Func 4 Func 2 • Internal Interfaces…continued • Decomposing functions, decomposes interfaces • They eventually end up in the product(hopefully). If not you have test & integration problems (or worse yetfield problems) • An interface represents an agreement between membersof your product. Agreementsneed to be documented • Don’t “lose” an interface • …all the bad things happen at interfaces • ...as documented by many of your SE application studies • …Dr. Stephen Wheelwright predicting next model year problems [SE Handbook 9.2] [DMSC 1986]

6. Losing interfaces… • Sayano-Shushenskaya Hydropower Plant (Aug. 2009) • Holding clamp fails due to vibration fatigue • Water pressure shoots 1500 tongenerator through the ceiling followed by 67,600 gallons/sec. • 73 million gallons flood the turbine room • 75 lose their lives • Toxic Transformer oil escapesinto the river killing 400 tons of fish • Power loss…3.8 million affected Popular Mech Feb. 2010

7. Losing interfaces… • San Bruno, CA Gas Pipe Explosion (Sept. 2010) • Power supply to a pressure sensor on a valve fails • Repairs cause pressure regulators/transmitters to malfunction; pressure surges • Undocumented seam welds fails, releasing gas and resulting explosion • 108 homes damaged, 8 losetheir lives • PG&E takes ½ hour to figureout how to shut off the valvesmanually Popular Mech Sept. 2011

8. Documenting Interfaces… • …as you drive down through function, interfaces are defined. • Interfaces show up in the product& need to be managed • Some tools for describinginterfaces: • NxN (aka ‘N-squared’) charts • Design Structure Matrix • Cross-Correlation Matrix • Functional Thread • …functions placed on diagonal. Information flowsclockwise between functions. Outputs are horizontal,inputs vertical. Interface name at the intersections. [SE Handbook 9.5] [Lacy 1992]

9. Documenting Interfaces…ICD’s • …interface agreements can also be documented in Interface Control Documents (ICD’s), Interface BlockDiagrams, Schematic Block Diagrams,… • Start with where you are (add details as available…) • Possibly includes: • Interface function—what theinterface must do, clarifiesresponsibilities of each end of the interface • Specify how well it must be performed • Define any constraints • Physical characteristics • Tools help generate these documents. [SE Handbook 9.5] [DOE 2003]

10. Documenting Interfaces…Data Dictionaries • …Data Dictionaries normally associated with documenting database schema, field names, etc. • …also applies to systems to document information exchange agreements. • Possibly includes: • Name • Information type • Default values • Brief Description • …delivered in referencable form • …common crib sheet • …usually under ICB control • Tools help generate these documents. [SE Handbook 9.2]

11. 787 Airplane Systems • Avionics • Common Core System (CCS) • Navigation - FMS • Navigation – TMS • Navigation – ADRS • Navigation – ERS • Navigation – IRS • Navigation – CM App • Displays and Crew Alerting • Integrated Surveillance • Communications – SATCOM • Communication - Recorders • e-Enabling (Crew Information System) • Maintenance Systems • Flight Controls • Flight Controls Electronics • High Lift • Primary Flight Controls • Autoflight • Integrated Standby Flight • Displays • Environmental Control Systems • Equipment Cooling • Moisture Control • Humidification • CACTCS • Cabin Pressure Control System • Cargo Air Conditioning, Ventilation • EE Cooling • Power Elect Cooling • Integrated Cooling System • Compressor Ice Prot. System (CIPS) • Cargo Fire Protection System • Engine Anti-Ice (EAI) System • Primary Ice Detection System • Wheel Well Fire Detection System • Rain Removal System (RRS) • Wing Ice Protection System (WIPS) • Mechanical • Wheels and Brakes • Brake Control and Monitor • Landing Gear Actuation • Nose Wheel Steering • Flight Deck • Flight Deck Control Panels • Flight Deck Area Illumination • Flight Deck Access System • Electrical Sub-systems • Cargo Compartment Lighting • Electrical Power Conversion • Primary Power Distribution • Remote Power Distribution • CBIC • Electrical Power Generation • Lighting • Proximity Sensing / Air-Ground • Current Return Network • Window Heat • High Voltage DC Racks and MC • Payloads • Cargo Handling System • Galley • Lavatories • General Lighting • Oxygen System • Water/ Waste System • Dimmable Windows • Cabin Systems • Broadband Offboard Satellite System • Cabin Services Systems • Emergency Lighting System • Inflight Entertainment System • Telephone System • Video Surveillance System • Hydraulics • Hydraulics, consisting of: • Electric Motor Pump • Hydraulics Subsystems • Hydraulic Distribution • Ram Air Turbine • Propulsion • EEC/EMU • Thrust Reverser System • Fire and Overheat Detection • Auxiliary Power System (APS) • Fuels • Fuel Quantity Indicating System • Nitrogen Generating System ~5000 sensors, ECU’s, etc. communicating over 9000 connections via 1,000,000+ types of messages, performing 2000+ functions—with each tail number different [PLM Connections 2007]

12. Integrated Modeling Success Story 1:Visibility and Metrics Result in Significant Decrease In Discrepancies • Discrepancies quickly identified and fixed prior to detailed lab testing and flight testing • 16,000+ publisher timing discrepancies 0 for BP3.0 • “Paper” discoveries made during analysis integration, not lab and test integration [PLM Connections 2007]

13. Integrated Modeling Success Story 2:System-To-System Interface Analysis • Validate receiving inputs from required systems (i.e. subscribed to correct publishers) • Validate other systems are subscribing to your outputs • Validate the number of parameters • Identify and resolve: • Under subscription • Over subscription • Incorrect subscription Subscribes • Note: • This is done at a high level to allow • the designers to assess the impact from both a publisher and subscriber perspective. • There are hundreds of thousands of parameters. It would be easy to “lose the forest for the trees” if unable to look at the data at different levels: • system • subsystem • component/LRU Publishes Subset of System-to-System Matrix Report is updated on a weekly basis [PLM Connections 2007]

14. Integrated Modeling Success Story 3:Bandwidth Reduction System/Subsystem BW Summary Subsystem Message BW Summary Dataset Summary Note: These charts reflect the 1/26 State of SLATE. [PLM Connections 2007]

15. Developing Alternatives… • Now that we have functions captured, there’s a variety of ways they can be accomplished. • Systems Engineering needs to do an unbiased review of as many alternatives/ “What if’s” as feasible. Why? Some possible solutions are better than others. • arrive at best possible overall solution (vs. sub-optimized) • creates robust designs (robust to change, etc.) • ensures you’re not backing into pre-selected solution • …a discussion about superballs… • Use your brainstorming techniques(described earlier) to build an alternatives list [SE Handbook 9.2]

16. Developing Alternatives…Morphological Charts • A structured method for widening search area for possible solutions… • Start with functions • List means for accomplishing functions (see also brainstorming) • Chart the functions & explorecombinations [betterproductdesign.net]

17. Developing/Evaluating Alternatives…Converging • Pugh’s Controlled Convergence… • …an iterative method of converging to the best possible solution among alternatives. • “sketch” the concepts • Develop the matrix—with criteria • Pick one potential solution as the datum • Compare each conceptagainst the datum • The best becomes the new datum • Combine, eliminate… • Repeat until design converges to acceptablesolution [Lacy 1992] [see also various web sites—like betterproductdesign.net]

18. Evaluating Alternatives…Criteria • How are you going to decide what is the best alternative? • Does it meet the contraints…pass/fail—does it meet the musts? • Does the best in scoring criteria & utility functions… • What criteria to use? • Should be tied to objectives (scope statement) • Ask the customer, stakeholders… • Cost, schedule, performance… • Competition… • Policies, vision/mission, values… • …should probably be done before developing alternatives to ensure an unbiased evaluation • Remember to capture your scoring criteria rationale • Document the why/how of your scoring so in case something changes you can go back and pick up that thread (and save someone else some time when they come to that same decision point) [Lacy 1992]

19. Evaluating Alternatives…Weighting • Not all criteria are of equal importance…weighting factors associated with criteria • How to determine the weighting factor? • Empirical—which criteria has the greatest impact on meetingobjectives (most expensive…) • Statistical—the scoring is mostsensitive to which criteria (ala DFSS) • Subjective—SME (subject matterexperts) scoring (methodsinclude fixed scoring budgets, judging best solutions & backing outweighting, pair-wisedecision trees…) [DMSC 1986] [Lacy 1992]

20. Evaluating Alternatives…Utility Curves • All criteria are not of equal importance…at different times, different performance levels,… • Loss: At what time/level does the benefitimprove/end/accelerate? • Some sample curves [DMSC 1986] [Lacy 1992]