Week 6 - Systems Engineering and Analysis

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

13. 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

14. 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.

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

16. Morphological Box for Auto Navigation Support System Figure 8.5

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

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

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

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

21. 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.

22. 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.

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

24. Example- Vehicle Theft

25. Vehicle Theft Example

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

27. 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

28. 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

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

30. Alternate Design Allocation Options Studied Figure 8.8

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

32. 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

33. 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

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

35. Software Implementation of Triplicated TMR Figure 8.10

36. Active Hardware Redundancy: Duplication with Comparison Figure 8.11

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

38. Pair-and-a-spare Figure 8.13

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

40. 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)

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

42. 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.

43. 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.

45. 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

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

48. 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

49. Step 2 – Allocate capabilities

50. Extra Slides See the last slide!