1 / 57

Week 6 - Systems Engineering and Analysis

Week 6 - Systems Engineering and Analysis. Buede ch 8 & Wasson ch 40 – Physical Architecture. Believe it or not – we’ll even apply this topic to the “Newton free” world of software! Image of “Second Life” from http://secondlifetalk.com/. Functional What the system must do. Physical

adonis
Download Presentation

Week 6 - Systems Engineering and Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Week 6 - Systems Engineering and Analysis Buede ch 8 & Wasson ch 40 – Physical Architecture Believe it or not – we’ll even apply this topic to the “Newton free” world of software! Image of “Second Life” from http://secondlifetalk.com/.

  2. Functional What the system must do. Physical How the system will do it. Buede starts here – for Wasson, see slide 47! Functional vs. Physical

  3. Physical Architecture • Provides system resources for every function in the Functional Architecture Resource types : • Hardware • Software • Facilities • People • Procedures

  4. Physical Architecture-2 • Must be a Physical Architecture for each system associated with the system life cycle. • Two types of Physical Architectures : • Generic and Instantiated.

  5. Physical Architecture-3 For software: • We are used to having a design experience that feels free of physical limitations! Don’t like the way the world actually looks? Add/change/delete your own features! Image from http://www.indiamike.com/india/chai-and-chat-f73/nasa-world-wind-software-t12187/

  6. Physical Architecture-4 For software: • “Physical” means “real” – like: • What families of components would we choose? • What “bottom up” characteristics would fit? • Without going all the way to naming those pieces • But this is systems engineering, and we also can learn from design work that does have some physical reality…

  7. Generic Physical Architecture for Elevator Figure 8.2

  8. Elevator First Level Functional Model

  9. Functional Allocation: 1-1 and ‘Onto’ Figure 8.4

  10. Functional Allocation Goal • Allocate Functions  Components. • There is great advantage to having Functional and Physical Architectures match (one-to-one and onto).

  11. Functional Allocation Goal • There is great advantage to having Functional and Physical Architectures match (one-to-one and onto). • When does this happen ?? • When does this not happen ?? Product or system architecture decisions ??

  12. Two Levels of Physical Architecture • Generic physical architecture: description of the partitioned elements of the physical architecture without any specification of the performance characteristics of the physical resources that comprise each element • Instantiatedphysical architecture: generic physical architecture to which complete definitions of the performance characteristics of the resources have been added

  13. The Process • Generic Physical Architecture provides ‘common designators’ for physical resources. (No real physical items). • Morphology Box to create and list instantiated architectures – options for choice. • Create many alternate instantiations to choose from.

  14. Morphological Box for Hammer (Top row – generic components, 320 possible combinations) Table 8.3

  15. Morphological Box for Auto Navigation Support System Figure 8.5

  16. We can use morphological boxes with software, too Image from http://hcil2.cs.umd.edu/trs/2004-17/2004-17.html

  17. Pairwise Infeasible Combinations within a Morphological Box Hammer Example Figure 8.6

  18. Matches first level Functional decomposition Compare lower levels to functional decomposition Is it 1-to-1 ??

  19. Block Diagrams of Physical Architecture(Most common graphical representation) Figure 8.7

  20. Block diagram for software Image from http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=hdwr&db=bks&fname=/SGI_EndUser/RASC_UG/ch04.html.

  21. Issues in Physical Architecture Development • Functional performance, availability (cost, safety, fault tolerance), and other system-wide traits. • Commercial and ‘product line’ factors. • Operational architecture finishes this process. • Looking ahead – physical architecture elements are added as mechanisms on the Functional Architecture to produce the Operational Architecture.

  22. Vehicle Theft Deterrence See https://www.youtube.com/watch?v=Ee3L9BQQ4Gs It’s fairly easy to understand conceptually how an effective system could work…

  23. Example- Vehicle Theft

  24. Vehicle Theft Example

  25. Major Conceptsfor Physical Architecture • Centralized vs. Decentralized • Modular vs. Integral • Standardization, Serviceability • ‘COTS’ components

  26. Mostly Software Example :FBI Fingerprint Identification System • IAFIS: Integrated Automated Fingerprint Identification System • ITN/FBI: Identification Tasking and Networking segment – focus of this case study • III/FBI: Interstate Identification Index segment • AFIS/FBI: Automated Fingerprint Identification System segment

  27. ITN/FBI: Identification Tasking and Networking • RFP identified subelements • TPS: Ten-print Processing Subelement was key • Processed paper cards with 10 fingerprints • Organized as work stations within a workgroup (distributed system) • Processed ~ 30,000 per day • Scanned, converted to binary data, and analyzed • Images had to be compressed by at least 10 to 1 • Average time to perform a fingerprint image comparison was 60 seconds • Time allowed for display of human-machine interface was 1 second from time of request

  28. Critical Design Issues for TPS • Implementation of wavelet scalar quantization (WSQ) algorithm (hardware vs. software) • Workstation capabilities • Server capabilities • Workflow management capabilities • Communications interface

  29. Alternate Design Allocation Options Studied Figure 8.8

  30. Morphological Box of Instantiated Design Option 2 new alternatives (g & h) identified Table 8.5

  31. Use of Redundancyto Achieve Fault Tolerance • Hardware: adds extra hardware to enable detection of and recovery from errors • Software: N-version • N different software developers for same routine • Comparison of results via voting • Seldom used due to expense of software development • Information: adding extra bits of information to enable error detection • Time: replaces hardware or software redundancy when there is slack processing time - recalculation

  32. Hardware Redundancy -A crucial choice for software • Passive: extra hardware operating concurrently using voting • Errors are masked or hidden (system unaware) • Approaches • N-modular redundancy (NMR) • Triplicated: TMR – masks 1 error • 5MR – masks 2 errors • Triplicated NMR • Active: detects errors, confines damage, recovers from errors, & isolates/reports fault • Duplication with comparison: extra hardware with comparison, not voting • Hot standby: extra hardware, only one reporting, monitor of outputs to detect error • Cold standby: extra hardware inactive until error detected • Pair-and-a-spare: Duplication with comparison & hot standby • Hybrid: combinations of the above

  33. TMR & Triplicated TMR Voter is single point of failure Issues with Voting Figure 8.9

  34. Software Implementation of Triplicated TMR Figure 8.10

  35. Active Hardware Redundancy: Duplication with Comparison Figure 8.11

  36. Hot Standby Sparing, N-1 Replicas Figure 8.12

  37. Pair-and-a-spare Figure 8.13

  38. Practicality of Redundancy • How practical is redundancy ? • In your car. • In an airplane.

  39. Redundancy Warning • Redundant components and systems must truly be independent systems. • Often a ‘single point of failure’ takes out all ‘redundant’ systems. • Space Shuttle Challenger (o-rings) • Genesis space vehicle (g-switches) • UA 232 Sioux City (hydraulic systems) (P.242)

  40. Discussion Q1 • The physical architecture for the hammer : • what does the functional architecture look like

  41. Discussion Q2 • For the drink machine functional architecture, does Hatley Pirbhai or ‘Energy, Materials, Signal Flows’ ‘work better’ with respect to giving a functional architecture that produces a ‘more realistic’ physical architecture.

  42. Discussion Q3 • For the ATM machine, develop an external systems diagram and a first level function decomposition for the Acme ATM Company – a manufacturer and seller of ATM machines. • Consider the possible uses of the functional model and physical implementations of the system.

  43. Discussion Q4 • Given the first level decomposition for the ATM machine: • Sketch the generic physical architecture • Sketch a morphological box and some possible instantiated physical implementations

  44. Wasson’s Ch 40 Let’s look at Wasson’s recommended methodology:

  45. Wasson’s “Domain solution challenges” (Sec 40.6) Solution space validation Technical design integrity Multi-domain solution agreement Risk identification and mitigation Environment, safety and health System solution stability System support Interfaces System optimization Phases and modes of operation

  46. Step 2 – Allocate capabilities

  47. Extra Slides See the last slide!

More Related